Software Engineering

(SE2223)
SOFTWARE REQUIREMENTS

• Something required, something wanted or

needed
(Webster’s dictionary)
• There is a huge difference between wanted and
needed and it should be kept in mind all the time

SE 2223 Software Engineering 2

SOFTWARE REQUIREMENTS

• A condition or capability that must be met or

possessed by a system...to satisfy a contract,
standard, specification, or other formally imposed
document
IEEE Definition

SE 2223 Software Engineering 3

SOFTWARE REQUIREMENTS PROCESS

• Processes used to discover, analyze and validate system

requirements

SE 2223 Software Engineering 4

FEASIBILITY STUDY

• A feasibility study decides whether or not the proposed

system is worthwhile
• The study checks
 If the system contributes to organizational objectives
 If the system can be engineered using current technology and within
budget
 If the system can be integrated with other systems that are used

SE 2223 Software Engineering 5

CONT…..
• Technical capability: Does the organization have the technical resources to undertake the project?
• Budget: Does the organization have the financial resources to undertake the project, and is the
cost/benefit analysis sufficient to warrant moving forward?
• Legality: What are the legal requirements of the project, and can the business meet them?
• Risk: What is the risk associated with undertaking this project? Is the risk worthwhile to the company
based on perceived benefits?
• Operational feasibility: Does the project, in its proposed scope, meet the organization’s needs by
solving problems and/or taking advantage of identified opportunities?
• Time: Can the project be completed in a reasonable timeline?

SE 2223 Software Engineering 6

FEASIBILITY STUDY CONT..

• Based on information collection, information assessment and

report writing
• Questions for people in the organization
 What if the system wasn’t implemented?
 What are current process problems?
 How will the proposed system help?
 What will be the integration problems?
 Is new technology needed? What skills?
 What facilities must be supported by the proposed system?
SE 2223 Software Engineering 7
REQUIREMENT ELICITATION AND ANALYSIS

• Involves technical staff working with customers to find

out about the application domain, the services that the
system should provide and the system’s operational
constraints
• Involves many stakeholders, such as end-users,
managers, engineers, domain experts etc.

SE 2223 Software Engineering 8

REQUIREMENT ELICITATION
• It is the practice of obtaining the requirements of a system from users, customers and
other stakeholders
 The practice is also sometimes referred to as Requirement Gathering
• Requirements elicitation practice include the following:
 Stakeholder analysis
 Analysis of existing systems or documentation, background reading
 Interviews
 Questionnaires
 User observation
 Workshops
 Story boarding
 Use cases
 Brainstorming
 Prototyping

SE 2223 Software Engineering 9

REQUIREMENTS ANALYSIS

• This step helps to determine the quality of the requirement

• The objective of this step is to identify
 Unclear
 Incomplete
 Ambiguous
 Contradictory
• These issues resolved before moving to the next step

SE 2223 Software Engineering 10

REQUIREMENTS SPECIFICATION

• A software requirements specification (SRS) is a description of

a software system to be developed
• Establishes the basis for an agreement between customers
and contractors or suppliers on how the software product
should function
• It contains sufficient and necessary requirements (functional +
Non-functional) for the project development

SE 2223 Software Engineering 11

SRS TEMPLATE

• Project Introduction
• Overall description
• External Interface Requirements
• System Requirements (functional/features)
• Non-functional requirements

SE 2223 Software Engineering 12

CONT….

SE 2223 Software Engineering 13

REQUIREMENTS VALIDATION

• It’s a process of ensuring the specified requirements meet the

customer needs
• It’s concerned with finding problems with the requirements
• During validation process, we perform
 Validity checks:
• The functions proposed by stakeholders should be aligned with what the system
needs to perform
 Consistency checks:
• Requirements in the document shouldn’t conflict or different description of the
same function

SE 2223 Software Engineering 14

REQUIREMENTS VALIDATION

 Completeness checks:
• The document should include all the requirements and constrains
 Realism checks:
• Ensure the requirements can actually be implemented using the knowledge
of existing technology, the budget, schedule, etc.
 Verifiability:
• Requirements should be written so that they can be tested. This means you
should be able to write a set of tests that demonstrate that the system
meets the specified requirements.

SE 2223 Software Engineering 15

REQUIREMENTS MANAGEMENT

• Requirements management process includes

 Defining the requirements baseline, a snapshot in time that represents an agreed-upon,
reviewed, and approved set of functional and nonfunctional requirements, often for a
specific product release or development iteration
 Evaluating the impact of proposed requirements changes and incorporating approved
changes into the project in a controlled way
 Negotiating new commitments based on the estimated impact of requirements changes
 Defining the relationships and dependencies that exist between requirements
 Tracing individual requirements to their corresponding designs, source code, and tests
(Requirement Traceability)
 Tracking requirements status and change activity throughout the project

SE 2223 Software Engineering 16

REQUIREMENTS RISKS

• Requirements risk is the potential for losses due to a project's requirements

themselves or the requirements management process
 Missing Stakeholders
 Wrong Stakeholders
 Ambiguous Requirements
 Incomplete Requirements
 Conflicting Requirements
 Infeasible Requirements
 Unverifiable Requirements
 Invalid Assumptions
 Lack of Traceability

SE 2223 Software Engineering 17

CHARACTERISTICS OF EXCELLENT
REQUIREMENTS
• Complete
• Correct
• Feasible
• Necessary
• Prioritized
• Unambiguous
• Verifiable

SE 2223 Software Engineering 18