Chapter 3
Requirement Engineering
Requirements engineering
• Requirements for a system are the description of the services provided by the system and its
operational constraints. It reflect the needs of customer for a system that help to solve
problem such as placing order or finding information.The process of finding out, analysis and
documenting these services and constraints called requirement engineering.
• It provides the appropriate mechanism for understanding what customer wants, analyzing
needs, assessing feasibility, specifying the solution unambiguously, validating the specification,
and managing the requirements
• ensure that a specified system properly meets the customer’s needs and satisfies the
customer’s expectation.
• The requirements engineering process steps
 requirements elicitation
 requirements analysis and validation
 requirements specification
 system modeling
 requirements management
Cont’
• Requirement - a wide range of statements of a service or of a system
constraint
• requirements is a description of needs or desires for a product
Types
• Functional requirements and Nonfunctional requirements
Functional requirements:- Statements of services the system should
provide
E.g.An operator must be able to
- define a new game
-Advertise a new league
-Schedule tournament
- Notify an interest group
Cont’
• Nonfunctional requirements describe aspects of the system that are
not directly related to the functional behavior of the system.
• constraints on the services or functions offered by the system such as timing
constraints, constraints on the development process, standards, etc.
• Performance requirements
 response time- how quickly the system reacts to a user input,
throughput - how much work the system can accomplish within a
specified amount of time
E.g. All user inputs should be acknowledged within 1 second”
 availability- the degree to which a or component is operational and
accessible when required for use
E.g. system is operational 24/7
• Usability is the ease with which a user can learn to operate, prepare
inputs for, and interpret outputs of a system or component.
• Supportability - concerned with the ease of changes to the system after deployment,
 Adaptability - the ability to change the system to deal with additional application
domain concepts
 maintainability- the ability to change the system to deal with new technology or to fix
defects
 internationalization - the ability to change the system to deal with additional
international conventions, such as languages, units, and number formats
 portability- the ease with which a system or component can be transferred from one
hardware or software environment to another
Reliability is the ability of a system or component to perform its required functions under
stated conditions for a specified period of time.
includes
 Robustness- the degree to which a system or component can function correctly in the
presence of invalid inputs or stressful environment conditions
 Example: The system can tolerate temperatures up to 90 C
 safety- measure of the absence of catastrophic consequences to the environment
Cont’
constraints requirements.
• Implementation requirements - constraints on the implementation of the
system, including the use of specific tools, programming languages, or
hardware platforms.
• Interface requirements - constraints imposed by external systems,
including legacy systems and interchange formats.
• Operations requirements - constraints on the administration and
management of the system in the operational setting.
• Packaging requirements - constraints on the actual delivery of the system
(e.g., constraints on the installation media for setting up the software).
• Legal requirements - concerned with licensing, regulation, and certification
issues. An example :- software developed for the U.S. federal government
must comply with Section 508 of the Rehabilitation Act of 1973, requiring
that government information systems must be accessible to people with
disabilities.
• Quality requirements for ATM
• Any user who knows how to read a Amharic or English should
be able to use the system the user manual. [Usability
requirement]
• customer should be prompt PIN within 1 sec after card is
inserted. [Performance requirement]
• All related software associated with system, will be written
using Java, to comply with current company policy.
[Implementation requirement]
Requirements Elicitation
• Eliciting requirements: the task of communicating with
customers and users to determine what their requirements
are. Such as
• what the objectives for the system
• what is to be accomplished
• how the system fits into the needs of the business
• how the system to be used on a day-to-day basis
• This is sometimes also called requirements gathering.
why requirements elicitation is difficult
Eliciting requirements is difficult because
• Problems of scope. The boundary of the system is ill-defined /
the customers/users specify unnecessary technical detail that may confuse
• Problems of understanding.
The customers/users
 are not completely sure of what is needed
 have a poor understanding of the capabilities and limitations of their computing
environment
 have trouble communicating needs to the system engineer
 omit information that is believed to be “obvious”
 specify requirements that are ambiguous or untestable
• Problems of volatility. The requirements change over time
solution
- To set guidelines for requirements elicitation, :
• Define one or more requirements elicitation methods (e.g.,
interviews, focus groups, team meetings).
• communicate many people so that requirements are defined from
different points of view
• Identify ambiguous requirements as candidates for prototyping
• Assess the business and technical feasibility for the proposed
system.
• Identify the people who will help specify requirements and
understand their organizational bias.
1
 techniques to elicit the requirements
• interview
• Questionnaires: Asking the end user a list of pre-selected
questions
• Task Analysis: Observing end users in their operational
environment
• prototyping
• combination of these methods
 sources of information including
• client-supplied documents about the application domain
• manuals and technical documentation of legacy systems
• the users and clients themselves
1
Requirements Analysis and
validation
• Analyzing requirements: determining whether the stated
requirements are unclear, incomplete, ambiguous, or
contradictory, and then resolving these issues.
because
• customers and users ask for more than what can be achieved
given limited business resources.
• different customers or users to propose conflicting requirements
1
Cont’
requirements should be precise, complete, and consistent
• Precise
• They should state exactly what is desired of the system
• Complete
• They should include descriptions of all facilities required
• Consistent
• There should be no conflicts or contradictions in the descriptions of the system
facilities
• Requirements validation: Concerned with demonstrating that the
requirements define the system that the customer really wants
• iteratively requirements are eliminated, combined, and/or modified
so that each party achieves some measure of satisfaction
1
Cont’
- the following questions used in analysis:
• Is each requirement consistent with the overall objective for
the system/product?
• Is each requirement bounded and unambiguous?
• Does each requirement have attribution? That is, is a source
(generally, a specific individual) noted for each requirement?
• Do any requirements conflict with other requirements?
• Is each requirement achievable in the technical environment
that will house the system or product?
• Is each requirement testable, once implemented?
1
• Here is an example of an invalid requirements set for an
electric water heater controller.
oIf 70° < Temperature < 100°, then output 3000 Watts.
oIf 100° < Temperature < 130°, then output 2000 Watts.
oIf 120° < Temperature < 150°, then output 1000 Watts.
oIf 150° < Temperature, then output 0 Watts.
• This set of requirements is incomplete, what should happen if
Temperature < 70°?
• This set of requirements is inconsistent, what should happen if
Temperature = 125°?
• These requirements are incorrect because units are not given.
Are those temperatures in degrees Fahrenheit or Centigrade?
Requirements Specification
• Main aim of requirements specification:
• systematically organize and record the requirements arrived
during requirements analysis
• document requirements properly.
• SRS(software requirement specification ) document is a contract
between the development team and the client.
• Once the SRS document is approved by the client, any
subsequent controversies are settled by referring the SRS
document.
1
Cont’
• Once client agrees to the SRS document:
• development team starts to develop the product according to
the requirements recorded in the SRS document.
• The final product will be acceptable to the client:
• as long as it satisfies all the requirements recorded in the SRS
document.
• The requirements at this stage:
• written using end-user terminology.
• SRS document, normally contains three important parts:
• functional requirements,
• nonfunctional requirements,
• constraints on the system
1
Requirements Management
• requirements change and that the desire to change
requirements persists throughout the life of the system.
• Requirements management is a set of activities that help the
project team to identify, control, and track requirements and
changes to requirements at any time as the project proceeds.
• Requirements management is the process of managing
changing requirements during the requirements engineering
process and system development
1
Requirements change
• New requirements emerge during the process as business needs
change and a better understanding of the system is developed
• The priority of requirements from different viewpoints changes
during the development process
• Client may specify requirements from a business perspective that
conflict with end-user requirements
• The business and technical environment of the system changes
during its development
1
Enduring and volatile requirements
• Enduring requirements. Stable requirements derived from the
core activity of the customer organisation. E.g. a hospital will
always have doctors, nurses, etc.
• Volatile requirements. Requirements which change during
development or when the system is in use. In a hospital,
requirements derived from health-care policy
2
System model
• Abstract descriptions of systems whose requirements are being analysed
• A model is an abstract view of a system that ignores system details.
Complementary system models can be developed to show the system’s
context, interactions, structure and behavior.
• System modeling is the process of developing abstract models of a system,
with each model presenting a different view or perspective of that system.
• representing a system using some kind of graphical notation
• System modelling helps the analyst to understand the functionality of the
system and models are used to communicate with customers
• Models of the new system
o are used during requirements engineering
o help explain the proposed requirements to other system stakeholders
o Engineers use these models to discuss design proposals and to document
the system
2
System perspective
• external perspective - model the context or environment of the
system.
• interaction perspective - models the interactions between a
system and its environment, or between the components of a
system.
• structural perspective - models the organization of a system or the
structure of the data that is processed by the system.
• behavioral perspective - models the dynamic behavior of the
system and how it responds to events
2
Context models
• Context models are used to illustrate the operational context of a
system
- they show what lies outside the system boundaries
• System boundaries are established to define what is inside and what
is outside the system.
• They show other systems that are used or depend on the system being
developed.
• A system context diagram (SCD) resides at the top level of the
hierarchy.
• The context diagram establishes the information boundary between
the system being implemented and the environment in which the
system is to operate
• the SCD defines all external producers of information used by the
system, all external consumers of information created by the system,
and all entities that communicate.
2
Context cont.
• It shows the people and/or systems that interact with the system
under construction.
• By interaction we mean putting information in or taking information
out of our system. This diagram gives an overview of the information
going in and coming out of the system.
• It is high level DFD that provides an overview of the data entering
and leaving the system.
• It also shows the entities that are providing or receiving that data.
These correspond usually to the people that are using the system we
will develop.
• The context diagram helps to define our system boundary to show
what is included in, and what is excluded from, our system.
The diagram consists of a rectangle representing the system
boundary, the external entities interacting with the system and the
data which flows into and out of the system.
Context diagram element
System/process
Data flow
External entity
Graphical representation
name
name
name
name
END!!
2