The document discusses requirements engineering and provides an overview of the requirements engineering process. It describes requirements elicitation, analysis and negotiation, specification, system modeling, validation, and management as the key steps in requirements engineering. Requirements engineering aims to understand customer needs, analyze and negotiate requirements, unambiguously specify the solution, and manage requirements as the system is developed. It provides the best process currently available for ensuring a system properly meets customer needs and expectations.

1. REQUIREMENTS
ENGINEERING
• The outcome of the system engineering process is the
specification of a computer based system
• But the challenge facing system engineers (and software
engineers) is profound: How can we ensure that we have: How can we ensure that we have
specified a system that properly meets the customer’s needsspecified a system that properly meets the customer’s needs
and satisfies the customer’s expectations?and satisfies the customer’s expectations?
• There is no foolproof answer to this difficult question, but a
solid requirements engineering process is the best solution we
currently have.
• Requirements engineering provides the appropriate
mechanism for understanding what the customer wants,
analyzing need, assessing feasibility, negotiating a reasonable
solution, specifying the solution unambiguously, validating the
specification, and managing the requirements as they are
transformed into an operational system

2. The requirements engineering
process can be described in
five distinct steps
• REQUIREMENTS ELICITATIONREQUIREMENTS ELICITATION
• REQUIREMENTS ANALYSIS ANDREQUIREMENTS ANALYSIS AND
NEGOTIATIONNEGOTIATION
• REQUIREMENTS SPECIfiCATIONREQUIREMENTS SPECIfiCATION
• SYSTEM MODELINGSYSTEM MODELING
• REQUIREMENTS VALIDATIONREQUIREMENTS VALIDATION
• REQUIREMENTS MANAGEMENTREQUIREMENTS MANAGEMENT

3. Requirements ElicitationRequirements Elicitation It certainly seems simple enough—ask the
customer, the users, and others what the objectives for the system or product are, what
is to be accomplished, how the system or product fits into the needs of the business, and
finally, how the system or product is to be used on a day-to-day basis. But it isn’t simple
—it’s very hard.
Requirements Analysis andRequirements Analysis and NegotiationNegotiation-Analysis
categorizes requirements and organizes them into related subsets; explores each
requirement in relationship to others; examines requirements for consistency,
omissions, and ambiguity; and ranks requirements based on the needs of
customers/users
Requirements SpecificationRequirements Specification The System Specification is the final
work product produced by the system and requirements engineer. It describes
the function and performance of a computer-based system and the constraints
that will govern its development. The specification bounds each allocated
system element. The System Specification also describes the information (data
and control) that is input to and output from the system
System ModelingSystem ModelingWe build system models for much the same
reason that we would develop a blueprint or 3D rendering for the kitchen. It is
important to evaluate the system’s components in relationship to one another,
to determine how requirements fit into this picture, and to assess the
“aesthetics” of the system as it has been conceived

4. Requirements Engineering
• Stakeholder identification
• Stakeholder interviews
• Contract-style requirement lists
• Measurable goals
• Prototypes
• Use cases

5. Who do this??

6. Who do this??
SystemSystem
engine-engine-
eringering
RequireRequire
mentment
analysisanalysis
SoftwareSoftware
engineerengineer

7. Software Requirements
Analysis and Specification
ANAM SINGLA
16071009

8. Software Requirement
Analysis• Determining the needs or conditions to meet for a new or
altered product,
• In other words, process of studying and analyzing the
customer and the user/stakaholder needs to arrive at a
definition of software requirements.
• Requirements must be actionable, measurable, testable,
related to identified business needs or opportunities, and
defined to a level of detail sufficient for system design.
• Requirements can be functional and non-functional.

9. Types of Requirements
• Functional requirementsFunctional requirements
• Performance requirementsPerformance requirements
• Speed, accuracy, frequency, throughput
• External interface requirementsExternal interface requirements
• Design constraintsDesign constraints
• Requirements are usually about “what”, this is a
“how”.
• Quality attributesQuality attributes
• i.e. reliability, portability, maintainability,
supportability

10. Requirements vs. Design
RequirementsRequirements DesignDesign
Describe what will beDescribe what will be
delivereddelivered
DescribeDescribe howhow it will be doneit will be done
Primary goal of analysis:Primary goal of analysis:
UNDERSTANDINGUNDERSTANDING
Primary goal of design:Primary goal of design:
OPTIMIZATIONOPTIMIZATION
There is more than oneThere is more than one
solutionsolution
There is only one (final)There is only one (final)
solutionsolution
Customer interestedCustomer interested Customer not interestedCustomer not interested
(Most of the time) except(Most of the time) except
for externalfor external

11. Software Quality AttributesSoftware Quality Attributes
 CorrectnessCorrectness
 ReliabilityReliability
 EfficiencyEfficiency
 IntegrityIntegrity
 UsabilityUsability
 SurvivabilitySurvivability
 MaintainabilityMaintainability
 VerifiabilityVerifiability
 FlexibilityFlexibility
 PortabilityPortability
 ReusabilityReusability
 InteroperabilityInteroperability
 ExpandabilityExpandability

12. Requirements Analysis
Defining Stakeholder profiles
• Description - brief description of the stakeholder typeDescription - brief description of the stakeholder type
• Type - Qualify expertise, technical background, degreeType - Qualify expertise, technical background, degree
of sophisticationof sophistication
• Responsibilities - List s-h’s key responsibilities withResponsibilities - List s-h’s key responsibilities with
regard to the system being developed - why aregard to the system being developed - why a
stakeholder?stakeholder?
• Success Criteria - How does the stakeholder defineSuccess Criteria - How does the stakeholder define
success? How rewarded?success? How rewarded?
• Involvement - involved in the project in what way?Involvement - involved in the project in what way?
Requirements reviewer, system tester, ...Requirements reviewer, system tester, ...
• Deliverables* - required by the stakeholderDeliverables* - required by the stakeholder
• Comments/Issues - Problems that interfere w/ success,Comments/Issues - Problems that interfere w/ success,
etc.etc.

13. Requirements Analysis
Defining User Profiles
• Description - of the user typeDescription - of the user type
• Type - qualify expertise, technical background, degree ofType - qualify expertise, technical background, degree of
sophisticationsophistication
• Responsibilities - user’s key resp.’s w.r.t. system beingResponsibilities - user’s key resp.’s w.r.t. system being
developeddeveloped
• Success Criteria - how this user defines success? rewarded?Success Criteria - how this user defines success? rewarded?
• Involvement - How user involved in this project? what role?Involvement - How user involved in this project? what role?
• Deliverables - Are there any deliverables the user produces?Deliverables - Are there any deliverables the user produces?
For whom?For whom?
• Comments/Issues - Problems that interfere w/ success, etcComments/Issues - Problems that interfere w/ success, etc.
• This includes trends that make the user’s job easier or harderThis includes trends that make the user’s job easier or harder

14. Requirements Analysis
Defining User Work Environment
• Number of people involved in doing this now?Number of people involved in doing this now?
Changing?Changing?
• How long is a task cycle now? Changing?How long is a task cycle now? Changing?
• Any unique environmental constraints: mobile,Any unique environmental constraints: mobile,
outdoors, in-flight, etc.outdoors, in-flight, etc.
• Which system platforms are in use today?Which system platforms are in use today?
future?future?
• What other applications are in use? Need toWhat other applications are in use? Need to
integrateintegrate?

15. Requirements Analysis
Product Overview
Put the product in perspective to other relatedPut the product in perspective to other related
products and the user’s environment.products and the user’s environment.
Independent?Independent?
Component of a larger system?Component of a larger system?
How do the subsystems interact with this?How do the subsystems interact with this?
Known interfaces between them and thisKnown interfaces between them and this
component?component?
Block diagramBlock diagram

16. Requirements Analysis
Other Product Requirements
• hardware platform requirements --hardware platform requirements --
• system requirements -- supported host o.s.’s,system requirements -- supported host o.s.’s,
peripherals, companion softwareperipherals, companion software
• environmental requirements -- temperature,environmental requirements -- temperature,
shock, humidity, radiation, usage conditions,shock, humidity, radiation, usage conditions,
resource availability, maintenance issues, type ofresource availability, maintenance issues, type of
error recoveryerror recovery
• applicable standards -- legal, regulatory,applicable standards -- legal, regulatory,
communicationscommunications

17. Requirements Analysis
• Fundamental Techniques (Views)
• functional view
• hierarchy - function tree
• process  use cases
• information ow  data flow diagram (DFD)
• data oriented view
• data structures  data dictionary (DD), syntax
diagram, Jackson diagram
• relations between entities  entity relationship
diagram (ER)
• object-oriented view
• class structure  class diagram

18. Requirements Analysis
• algorithmic view
• control structures
• pseudo code, structogram, flow diagram, Jackson
diagram
• conditions  rules, decision table
• state-oriented view
• state machines
• Petri nets
• sequence charts

19. Use Case
• use case is a description of a system’s behavior as it responds
to a request that originates from outside of that system.
• it describes "who" can do "what" with the system in question

20. Use Case Diagram
• A use case diagram
• in the Unified Modeling Language (UML)
• a type of behavioral diagram defined by and created
from a Use-case analysis.
• Its purpose is to present a graphical overview of the
functionality provided by a system in terms of actors,
their goals (represented as use cases), and any
dependencies between those use cases.
• The main purpose
• to show what system functions are performed for
which actor.
• Roles of the actors in the system can be depicted.

21. Use Case Diagram

22. Data Flow Diagram (DFD)
• graphical representation of data flow (classical
technique)
• nodes:
• function  labeled circle
• store name  between two horizontal lines
• interface to environment  labeled rectangle
• directed edges: represent data flow
• properties of DFDs
• easy to create
• easy to read and understand

23. Data Dictionary
• A data dictionary is a collection of data about datadata about data.
• It maintains information about the definition, structure, and
use of each data element that an organization uses.

24. Software Requirement
Specification
• A software requirements specification (SRS) is a complete
description of the behavior of the system to be developed
• A document that clearly and precisely describes, each of the
essential requirements of the software and the external
interfaces.
• (functions, performance, design constraint, and quality attributes)
• Each requirement is defined in such a way that its
achievement is capable of being objectively verified by a
prescribed method; for example inspection, demonstration,
analysis, or test.2

25. Software requirements specification
• Functional and Non-functional SRS
• IEEE 830-1998.

26. IEEE Std 830-1998 IEEE Recommended
Practice for Software Requirements
Specifications -Description
• Abstract: The content and qualities of a good software
requirements specification (SRS) are described and several
sample SRS outlines are presented. This recommended
practice is aimed at specifying requirements of software to be
developed but also can be applied to assist in the selection of
in-house and commercial software products. Guidelines for
compliance with 12207.1-1997 are also provided.
• Keywords: contract, customer, prototyping, software
requirements specification, supplier, system requirements
specifications

27. SRS
• Customer RequirementsCustomer Requirements
• Functional RequirementsFunctional Requirements
• Non-functional RequirementsNon-functional Requirements
• Performance RequirementsPerformance Requirements
• Design RequirementsDesign Requirements
• Derived RequirementsDerived Requirements
• Allocated RequirementsAllocated Requirements

28. THANK YOU…