Requirements Engineering

Lecture 04

7th October 2019

 Requirement
• The hardest single part of building a software system is
deciding what to build….
• No other part of the work so cripples the resulting system if
done wrong.
• No other part is more difficult to rectify later.

F.P Brooks
 Requirement
• Software Requirement stimulates what must be
– Accomplished,
– Transformed,
– Produced or Provided
• Additionally, a Software Requirement is a software capability that
must be met or possessed by a software component in order to
satisfy a contract, standard, or specification
• The source of these Requirements could come from
– Client/Customer
– Buyers,
– Users/End user, or system specifications
 Requirement Engineering
• The description of the services and constraints are the
requirements for the system and
• The process of
– Finding out,
– Analyzing,
– Documenting and
– Checking these services and Constraints are called
Requirements Engineering.”

Ian Sommerville
 Why are requirements important?
• The requirements are how we communicate
• They are the only part that everyone understand

CUSTOMER

USER DEVELOPER

Requirements
 How are Programs Usually Written …

The requirements The developers This is how the

specification was understood it in problem is
defined like this that way solved now

This is how the program is

described by marketing
That is the program after This, in fact, is what the
department
debugging customer wanted … ;-)
 Why are requirements important?
• Inconsistent and incomplete requirements are the most
frequent causes of the system problems
Incomplete requirements

Lack of user involvement

Lack of resources

Unrealistic expectations

Lack of executive support

Changing requirements

Lack of planning

System no more needed

10% 20% Causes of the failed projects

 Requirement Types
• Needs
– The capabilities and characteristics required in the
software system to solve the problem.
• Wishes/Wants
– The capabilities and characteristics of the
software system desired by the users.
• Expectations
– The capabilities and characteristics of the
software system expected by the users.
 Software Requirement Specification
Document

• SRS (Software Requirement specification)

• The official statement of what is required by the system
developers
• The goal of the SRS is to describe all externally observed
behaviors and characteristics expected of the software
system
• Includes user requirements and system requirements
• Standards for SRS
– RUP
– IEEE
– Ian Summerville
 Characteristics of SRS
• Correct
– All requirements stated in the SRS are one that the software
shall meet.
• Unambiguous
– Every requirement stated in the SRS only has one logical
interpretation.
• Complete
– The SRS includes all significant requirements
– The SRS includes all realizable classes of input data
– The SRS includes full labels and references to all figures, tables
and diagrams.
 Characteristics of SRS

• Verifiable
– For every requirement stated in the SRS, there exists some
finite cost-effective process with which a person or
machine can check that the software meets the
requirements.
• Modifiable
– The entire SRS has a style and structure such that any
changes to the requirements can be made
• Easily,
• Completely, and
• Consistently and retaining the structure and style.
 Characteristics of SRS

• Consistent
– No subset of individual requirements stated in the SRS
conflict with other individual requirements. 
• Traceable
– For every requirement stated in the SRS, it is clear of the
requirements origin and it is possible to reference each
requirement in future developments.
 Advantages of SRS

• The SRS can establish the basis for contractual agreement between
the customer and developers.
• The SRS can establish the basis for performing cost, schedule, and
resource estimates for the developmental effort.
• The SRS can provide a baseline for verification and validation of the
software.
 Types of SRS
• Production of System Specification
– Written document
– Graphical model
– Formal mathematical model
– Usage scenarios
– Prototype
– Any combination of above
 IEEE Standard
• Introduction

– Purpose of the requirement document

– Scope of the product

– Definitions, acronyms, and abbreviations

– References
 IEEE Standard
• General description

– Product Perspective
– Product functions
– User characteristics

– General constraints
– Assumption and dependencies
– Specific Requirements
– Appendices
– Index
 Why Engineer Requirement
• Wicked problems
– Most large software systems address wicked problems
– Problems which are so complex that they can never be fully
understood and where understanding evolves during the
system development
– Therefore, requirements are normally both incomplete and
inconsistent
 Requirement Types

• Functional Requirements
– The functional requirements define the fundamental actions that
the software must perform.
– The actions describes accepting inputs, processing, and
generating the outputs.
• Behavioral Requirements
– The behavioral requirements define the actions taken when the
software responds to internal and external stimulus.
– This includes describing what event causes an activity to start up
and the event that causes it to stop.
 Requirement Engineering Process

Requirement Engineering
– All activities devoted to
• Identification of user requirements,
• Analysis of the requirements to drive additional
requirements,
• Documentation of the requirements as a specification
• Validation of the documented requirements against user
needs, as well as processes that support these activities.
 Requirement Engineering Process
• Software Requirement Elicitation
– The process through which the customers, buyers or the
users of software system discover, reveal, articulate and
understanding their requirements
– Software Requirements Elicitation is any activity that has
as its objectives to:
• Gather,
• Determine,
• Extract, or expose software requirements
 Requirement Engineering Process
• Software Requirement Analysis
– The process of reasoning about the requirements that have
been elicited .
– Involves examining requirements for conflicts or
inconsistencies, combining related requirements, and
identifying missing requirements
– Software Requirements Analysis is any activity that has as its
objective to
• Organize,
• Interpret,
• Understand,
• Classify, or assess feasibility,
• Completeness, or consistency of software requirements.
 Requirement Engineering Process
• Software Requirement Specification
– The process of recording the requirements in one or more forms,
including natural language and formal, symbolic, or graphical
representations
– Software Requirements Specification is any activity that has as its
objective to capture a description of the software requirements
– Usually the final form of this description is a software
requirements specification (SRS).
• Software Requirement Validation
– The process of confirming with the customer or user of the
software that the specified requirements are valid, correct, and
complete
– Software Requirements Validation is any activity that has as its
objective to obtain buyer approval of the specification of the
software requirements.
Requirement Engineering Process

Feasibility Requirements
study elicitation and
analysis
Requir ements
specification
Feasibility Requirements
report validation
System
models
User and system
requirements

Requirements
document
 Requirement Engineering Process

• In reality these processes cannot be performed

sequentially
• All process are intertwined and performed repeatedly
• Elicitation is not universally accepted
– Identifying
– Gathering
– Determining
– Formulating
– Extracting
– Exposing
Outcomes of Requirement Elicitation

 
• Tangible
• Intangible
 Outcome of a Good Elicitation Process

• Users Perspective
– The users will have a better understanding of their needs and
constraints.
– The users will be in a position to evaluate alternatives and
understand the implications of their decisions.
– This level of understanding is extremely important since it is
usually the users who drives the requirements, which in turn
drives the design and implementation of the entire software
system.
– Thus, the quality of the requirements document is related to the
users understanding of the issues and tradeoffs involved.
Outcome of a Good Elicitation Process

• Users Perspective
– The users and the developers form a common vision of the
problem and the conceptualized software solution.
– To strive for this common understanding of all individuals
involved in the software engineering process
– A sense of ownership
– Feel informed and educated
– Committed to the success of the project
 Outcome of a Good Elicitation Process

• Developers Perspective

– This is the fundamental process that will be used to

construct a clear high level specification of the
problem that is to be solved.
– Other outcomes of a good elicitation process are
developers who:
• Are developing a solution to the right problem
• Are solving a problem that is feasible from all perspectives
• Have a high level specification of the solution
• Have cooperative users
Outcome of a Good Elicitation Process

• Developers Perspective
• Have all the necessary information, explanations, and
justifications
• Can make proper design justifications
• Need minimal ongoing interactions with the users
• They have trust and confidence of the customer
• Knowledge of the domain of the system
 Difficulties in Requirement Elicitation
• The process of elicitation of requirements is a difficult process.
– No single person has the complete picture.
– Work effectively as a coherent group.
– The following are some common difficulties associated with this process:
• Articulation Problems
– Expression/ Communication
– Articulation problems can occur because the users are usually experts in
their application domain but not in the process of engineering software.
– Additionally, the engineers are experts in development and not in the
users application domain.
– This problem is magnified by the users and developers having different
vocabulary, terms, and concepts
 Difficulties in Requirement Elicitation

Articulation of the users needs

• The users may not be aware of their needs
• Users who are unwilling to prioritize and make tradeoffs
• The users may be aware of needs but be afraid to articulating it
• Users and developers misunderstand concepts or relationships
• User cannot make up their minds
• No single person has complete picture
• Developers may not really be listening to the users
 Difficulties in Requirement Elicitation

• Articulation of the users needs

• Developer may fail to understand, appreciate, or relate to the
users
• Developers who are not skilled in listening
• Developers who are dominating in their approach to elicitation
• Developers who are solution not problem orientated
 Difficulties in Requirement Elicitation

• Communication Barriers
 Communication is not a single direction information flow
 Users and developers come from different worlds and have
different professional vocabularies
 The users have different concerns from those of developers
 Medium of communication-Natural language are inherently
ambiguous
 People involved are different-some are submissive, some are
assertive
 There are different value system among people
 Difficulties in Requirement Elicitation

• Problem Complexity
– The complexity of modern software system makes the process of
requirements elicitation extremely difficult.
– These systems have interconnections between subsystems and
environments that even expert in specialized disciplines have
difficulty understanding.

•  Nature of Requirements
• Requirements change and migrate
• Users learn and grow
• Requirements are diverse and conflicting
• Multiple views can be difficult to integrate
• Requirements can be difficult to evaluate.
 Difficulties in Requirement Elicitation

• Knowledge and Cognitive Limitations

• Tunnel vision
• User and Developers don’t have adequate domain knowledge
• No person has perfect memory
• Interpretation of statistics
• Problem simplification and ignoring part of the problem
because of complexity
• Some people are uncomfortable or impatient with exploration
Difficulties in Requirement Elicitation
• Human Behavioral Issues
– Elicitation is a social process
– Everyone (users) assumes that it is not his/her responsibility to tell the
developers
– Developer may assume that user will give the information
– User may assume that developer will ask appropriate questions

– Expectation and /or fears from proposed system

• Technical Issues
– Obsolete requirement by the time the elicitation process is completed

– Software and hardware technologies (corporate management, government

regulations, sales and marketing department)
Requirements phases with Techniques
• Requirement Elicitation Techniques
– Prototyping
– Contextual Inquiry
– Brainstorming
– Interviewing
– Questionnaire
• Requirements Analysis Techniques
– Interface designing
– ERD
– DFD
• Requirement Specification Techniques
– SRS
– Use cases
– scenarios
• Requirements Validation
 Key Points
• Requirements set out what the system should do and define
constraints on its operation and implementation.
• Functional requirements set out services the system should provide.
• Non-functional requirements constrain the system being developed
or the development process.
• User requirements are high-level statements of what the system
should do. User requirements should be written using natural
language, tables and diagrams.
• System requirements are intended to communicate the functions
that the system should provide.
• It is very difficult to formulate a complete and consistent
requirements specification
• Volatile requirements are dependent on the context of use of the
system
 Key Points
• A software requirements document is an agreed statement of the
system requirements.
• The IEEE standard is a useful starting point for defining more detailed
specific requirements standards.
• A requirements definition, a requirements specification and a software
specification are ways of specifying software for different types of
reader
• The requirements document is a description for customers and
developers
• Requirements errors are usually very expensive to correct after system
delivery
• Reviews involving client and contractor staff are used to validate the
system requirements