Software Requirement Engineering

Chapter 1: Requirement Engineering

1. Definition of RE: The process of establishing the services that the customer
requires from a system & the constraints under which it operates & is
developed.
2. Req.: may range from a high-level abstract statement of a service/of a
system to a detailed mathematical functional specification.
3. Type of Req.:
- User Req.: statements in natural language + diagrams of the services
the system provides & its operational constraints. Written for customers.
- System Req.: A structured document setting out detailed descriptions of
the systems function, services & operational constraints. Define what
should be implemented so may be part of a contract between client &
contractor.
4. Functional & Non-functional Req.
- Functional Req.
o Statements of services the system should provide, how the system
should react to particular inputs & how system should behave in
particular situations.
o May state what the system should do
o Req. Imprecision
Ambiguous req. may be interpreted in diff. ways by
developers & users.
o Req. Completeness & Consistency
Req. should be complete
Complete: They should include descriptions of all facilities
required.
Consistent: They should be no conflicts/contradictions in the
descriptions of system facilities.
- Non-functional Req.
o Constraints on the services or function offered by the system such
as timing constraints, constraint on the dev process, std..
o Type of Non-functional req.

Non-functional Req. Implementation

May affect the overall architecture of a system rather than
individual
May generate a number of related functional req. that define
system services that are required.
May generate req. that restrict existing req.
Non-functional Req. Classifications
Product Req.
Req. which specify that the delivered product must
behave in a particular way
Organizational Req.
Req. which are a consequence of organizational
policies & procedures
External Req.
Req. which arise from factors which are external to the
system & its dev. Process
Goals & Req.
Goal: A general intention of the user such as ease of use.
Verifiable Non-functional Req.: A statement using some
measure that can be objectively tested
Metrics for Specifying Non-functional Req.

Domain Req.
o Constraints on the system from the domain of the operation
o Problems:
Understandability
Req. expressed in language of the application domain
Implicitness
Domain specialist understand the area so well that
they do not think of making the domain req. explicit.

Chapter 2: Requirements Engineering Process

1. Processes
- Process: an organized set of activities which transforms inputs to output
2. Software Development Process
- A structured set of activities required to develop a software system.
- Software processes:
o Specification
o Design
o Validation
o Evolution
3. Software Process Model
- An abstract representative of a process
- Present a description of a process from some particular perspective
- Process descriptions may include:
o Products: the outcomes of a process activity
o Roles: reflect the responsibilities of the people involved in the
process
o Pre- & Post-conditions: statements that are true before and after
a process activity has been enacted or a product produced
- Types of Software Process Model
o Plan-driven processes
All of the process activities are planned in advance and
progress is measured against this plan

Waterfall

Incremental

Agile processes
Planning is incremental and it is easier to change the process
to reflect changing customer requirements.
Principle

XP Practices

4. Req. Eng. Process

- Generic Activities
o Req. Elicitation
o Req. Analysis
o Req. Validation
o Req. Management

RE Process : Inputs & Outputs

RE Process Variability
o Vary radically from one organization to another
o Factors
Technical maturity
Disciplinary involvement
Organizational culture
Application domain
5. Requirements Elicitation & Analysis
- Req. gathering/Req. discovery
- Involves technical staff working with customer to find out about
application domain, the services that the system should provide & the
systems operational constraints.
- May involve end-users, managers, engineers involved in maintenance,
domain experts, trade unions (STAKEHOLDERS)
- Types of Stakeholder
o Software engineers responsible for system development
o System end-users who will use the system after it has been
delivered
o Managers of system end-users who are responsible for their work
o External regulators who check that the system meets its legal
requirements
o Domain experts who give essential background information about
the system application domain
- Stages in Req. Elicitation & Analysis Process
o Req. discovery
Interacting with
stakeholders to discover
their req.
Domain req. are also
discovered at this stage
o Req. classification &
organization
Groups related
requirements and
organizes them into
coherent clusters

o
o

Req.

Req.

prioritization & negotiation

Prioritizing req. and resolving req. conflicts
specification
Req. are documented and input into the next round of the
spiral

Problems:
o Stakeholders dont know what they really want.
o Stakeholders express req. in their own terms.
o Different stakeholders may have conflicting req.
o Organizational and political factors may influence the system req.
o The req. change during the analysis process. New stakeholders may
emerge and the business environment change
6. Req. Validation
- Concerned with demonstrating that the req. define the system that the
customer really wants
- Criteria:
o Validity. Does the system provide the functions which best support
the customers needs?
Consistency. Are there any requirements conflicts?
Completeness. Are all functions required by the customer
included?
o Realism. Can the requirements be implemented given available
budget and technology
o Verifiability. Can the requirements be checked?
Techniques:
o Requirements reviews
Systematic manual analysis of the requirements.
o Prototyping
Using an executable model of the system to check
requirements.
o Test-case generation
Developing tests for requirements to check testability.
Req. Reviews
o Regular review should be held while req. definitions is being
formulated.
o Involved the client & contractor staff
o Reviews may be formal/informal
o Review Checks
Verifiability
Is the requirement realistically testable?
Comprehensibility
Is the requirement properly understood?
Traceability
Is the origin of the requirement clearly stated?
Adaptability
o
o

Can the requirement be changed without a large

impact on other
requirements?

7. Req. Management
- Process of managing changing req. during the req. eng. Process & system
dev.
- New req. emerge as system being dev
- Changing Req.
o Business & technical environment of the system always changes
after installation
o The people who pay the system & user are not the same people
- Change Analysis & Costing

Req. Evolution

Req. Management Planning

o Decision:
Requirements identification
Each req. must be uniquely identified so that it can be
cross referenced with other req.
A change management process
This is the set of activities that assess the impact and
cost of changes. I discuss this process in more detail in
the following section.
Traceability policies

These policies define the relationships between each

req. and between the req. and the system design that
should be recorded.
Tool support
Tools that may be used range from specialist req.
management systems to spreadsheets and simple
database systems.
Req. Traceability
o Information which helps you assess the impact of req. change. It
links related req. and the req. and other system representations
o Approach:
Backward-from traceability
Links req. to their sources in other documents or
people
Forward-from traceability
Links requirements to the design and implementation
components
Backward-to traceability
Links design and implementation components backs to
req.
Forward-to traceability
Links other documents (which may have preceded the
req. document) to relevant req.

Types of Traceability
Req.-sources traceability
Links the req. and the people or documents which
specified the req.
Req.-rationale traceability
Links the req. with a description of why that req. has
been specified.
Req.-req. traceability
Links req. with other req. which are, in some way,
dependent on them. This should be a two-way link
(dependents and is dependent on).
Req.-architecture traceability
Links req. with the sub-systems where these req. are
implemented. This is particularly important where subsystems are being developed by different subcontractors
Requirements-design traceability

Req.

Links req. with specific hardware or software

components in the system which are used to
implement the req.
Requirements-interface traceability
Links req. with the interfaces of external systems
which are used in the provision of the req.
Change Management
Problem analysis & change specification
Change analysis & costing
Change implementation

8. RE Process Problems
- Lack of stakeholder involvement
- Business needs not considered
- Lack of requirements management
- Lack of defined responsibilities
- Stakeholder communication problems
- Over-long schedules and poor quality requirements documents

Chapter 3: Feasibility Study

1. Feasibility Study
- To find out whether the system is worth implementing & if it can be
implemented, given the existing budget & schedule.

Input to the feasibility study:

o A set of preliminary business req.
o An outline description of the system & how the system is intended
to support business process
Outcome of feasibility study: report to recommend on doing the RE &
system dev process or not

2. Feasibility Study & Analysis

- Feasibility Study measure of how beneficial/ practical the dev. of an
information system to an organization
- Feasibility Analysis the process by which feasibility is measured.
- Characteristic of feasibility study:
o Inexpensive
o Quick
o Accurate
- Purpose:
o Helps answer the question of whether to go forward with the
software requirements.
o Evaluate alternatives
The feasibility study helps to frame and flesh-out specific
requirements scenarios so they can be studied in-depth.
Study results
Outline in depth the various requirements scenarios
examined and
the implications, strengths and weaknesses of each.
o Go/No Go decision
Information source in making critical decision
3. Data Source for Feasibility Assessment
- Can come from primary or secondary sources
o Primary: formal interviews & survey
o Secondary: industry & trade publications, statistic of industry
associations & government agency reports.
4. Four Common Areas of Feasibility Study
- Operational Feasibility
- Technical Feasibility
o

Schedule Feasibility
Economic Feasibility (cost-benefit analysis)

Chapter 4: Req. Elicitation

1. Elicitation Activities
- Application domain understanding
o Knowledge of the general area where the system is applied.
- Problem understanding
o Details of specific customer problem where the system will be
applied must be understood.
- Business understanding
o Must understand how systems interact & contribute to overall
business goals.
- Understanding the needs & constraints of system stakeholder
o Must understand in detail, the specific needs of people who require
system support in their work
2. Elicitation Phases/Stages

Objective Setting
o An outline descriptions of the problem to be solved, why the system is
necessary & constraints on the system.
- Background knowledge
acquisition
o Background info about system,
the application domain of the
system & info about existing
systems.
- Knowledge organization
o The information collected need
to be organized & collated.
- Stakeholder req. collection
o System stakeholders are
consulted to discover their requirements
3. Req. Analysis & Negotiation
- Req. Analysis
o Necessity checking

o
o

Consistency & completeness

checking
Feasibility checking

- Req. Negotiation
o Req. Discussion: problematic req. being discussed
o Req. Prioritization: identify critical req.
o Req. Agreement: solution to req. problems are identified
4. Elicitation Techniques
- Specific techniques which may be used to collect knowledge about system
req.
- Structure of knowledge:
o Partitioning - aggregating related knowledge
o Abstraction - recognizing generalities
o Projection - organizing according to perspective
- Elicitation problems
o Not enough time for elicitation
o Inadequate preparation by engineers
o Stakeholders are unconvinced of the need for a new system
- Elicitation Methods
o Interviews
Formal/informal interviews with stakeholder
Type of interview
Closed interview: based on pre-determined list of
questions
Open interview: various issues are explored with
stakeholders
Effective interviewing
Be open-minded, avoid pre-conceived ideas about req. &
listen to stakeholder
Prompt interviewee to get discussing, req. proposal,
working together on prototype
o Scenarios
Based on real-life stories/examples of how a system can be
used.
Include:
Description of starting situation
Description of normal flow of events
Description of what can go wrong
Info about other concurrent activities
Description of the state when scenario finishes

o
o
o

Observation & Social analysis

Req. reuse
Prototyping
An initial version of a system which may be used for
experimentation
User can experiment the system and point out its strength &
weaknesses
Benefits:
The prototype allows users to experiment and discover
what they
really need to support their work
Establishes feasibility and usefulness before high
development costs are incurred
Essential for developing the look and feel of a user
interface
Can be used for system testing and the development of
documentation
Forces a detailed study of the requirements which reveals
inconsistencies and omissions
Types of Prototyping:
Throw-away
o To help elicit & develop the system req.
Evolutionary
o To deliver a workable system quickly to the
customer
Cost & Problems
Training costs - prototype development may require the
use of special purpose tools
Development costs - depend on the type of prototype
being developed
Extended development schedules - developing a
prototype may extend the schedule although the
prototyping time may be recovered because rework is
avoided
Incompleteness - it may not be possible to prototype
critical system req.
Approach:
Paper prototyping
o a paper mock-up of the system is developed and
used for system experiments
Wizard of Oz prototyping
o a person simulates the responses of the system in
response to some user inputs
Executable prototyping

a fourth generation language or other rapid

development environment is used to develop an
executable prototype

5. Req. Analysis
- To discover problems, incompleteness & inconsistencies in the elicited req.
- Interleaves with elicitation as problems are discovered when the req. are
elicited
- Problem checklist may be used to support analysis.
- Analysis Checklist
o Premature design
Does the req. include premature design or implementation
information?
o Combined req.
Does the description of a req. describe a single req. or could it
be broken down into several different req.?
o Unnecessary req.
Is the requirement gold plating? That is, is the requirement a
cosmetic addition to the system which is not really necessary?
o Use of non-standard hardware
Does the req. mean that non-standard hardware or software
must be used? To make this decision, you need to know the
computer platform req.
o Conformance with business goals
Is the req. consistent with the business goals defined in the
introduction to the req. document? Req. ambiguity
o Req. ambiguity
Is the requirement ambiguous i.e. could it be read in different
ways by different
people? What are the possible interpretations of the req.?
o Req. realism
Is the req. realistic given the technology which will be used to
implement the system?
o Req. testability
Is the req.t testable, that is, is it stated in such a way that test
engineers can derive a test which can show if the system meets
that req.?