Transcript Requirements Engineering - Computer Science Department …

Requirements Engineering
CS350 Object-Oriented Software Engineering
Software Development Life Cycle
Requirements Engineering


A systems and software engineering process
which covers all of the activities involved in
discovering, documenting and maintaining a
set of requirements for a computer-based
system
A sub-discipline of systems and software
engineering and is concerned with
establishing the goals, functions and
constraints of hardware and software
systems
Requirements Engineering
Requirements inception
 Requirements identification

◦ Identifying new requirements

Requirements analysis and negotiation
◦ Checking requirements and resolving stakeholder
conflicts

Requirements specification
(Software Requirements Specification)
◦ Documenting the requirements in a requirements
document
Requirements Engineering

System modeling
◦ Deriving models of the system, often using a notation
such as the Unified Modeling Language

Requirements validation
◦ Checking that the documented requirements and
models are consistent and meet stakeholder needs

Requirements management
◦ Managing changes to the requirements as the system
is developed and put into use
Requirements Engineering
Feasibility study
 Elicitation & analysis
 Requirements analysis

Feasibility Study
Commences after project request phase
 Assesses the feasibility of providing an IT
solution for the request
 Quantifies the requirements, scope, costs,
benefits and other implications of the
proposed solution

Feasibility Study

The findings and recommendations should
be documented in a report, which
comprises two parts
◦ Management Summary
◦ Technical Specification
Management Summary

Approval Sought
◦ Highlight the major recommendations of the
Feasibility Study.

System Objectives
◦ State study objectives and intended usage of
the proposed system.

Background
◦ Describe the background picture and other
relevant information of the proposed system.
Management Summary

Present Situation
◦ Describe briefly the current operations,
environment and functions of the system
under study

Problem/Improvement Areas
◦ Describe the problems encountered or
anticipated and improvement areas identified
Management Summary

Proposed System
◦ Describe in high level terms the proposed
system and define the scope of the
subsequent SA&D study.

Resource Implications
◦ Estimate the resource requirements and
other implications of the proposed system.

Costs
◦ Estimate the non-recurrent and recurrent
costs of the proposed system
Management Summary

Benefits
◦ Estimate the tangible and intangible benefits of
the proposed system
◦ Realizable benefits, such as reduction in
expenditures, increases in revenue, and staff
savings resulting from deletion of posts, should
be expressed in financial terms. Where notional
or intangible benefits are quoted, the study
should include appropriate productivity and
performance indicators for measuring these
improvements subsequently
Management Summary

Cost-benefits Analysis
◦ Evaluate the cost effectiveness of the
proposed system with indications of the
funding requirements and timing for
realization of the identified benefits
Management Summary

Implementation Plan
◦ Schedule an implementation plan, with
detailed planning on appropriate
implementation stages, which should be in the
format specified in the adopted project
management method, e.g. project technical
plan in PRINCE

Recommendations
◦ Make study recommendations and propose
the way forward
Feasibility Study Technical
Specification

Current Environment Description
◦ Describe current operations and environment
◦ Describe current functions and data

Project Definition
◦ Describe the user requirements
◦ Describe the proposed system, in terms of its functions, data,
workload and user impact
◦ Describe the implementation approach and, if any, development
strategy
◦ Define the implementation plan and its cost/resource
implications with detailed backing information (e.g. Function
Point calculation, sizing, etc)
Elicitation & Analysis

Requirements elicitation
◦ The practice of collecting the requirements of
a system from users, customers and other
stakeholders
◦ Also referred to as requirements gathering
Elicitation & Analysis:
Problems
Scope
 Understanding
 Volatility

Elicitation & Analysis:
Problems

Scope
◦ The boundary of the system is ill-defined or
the customers/users specify unnecessary
technical detail that may confuse, rather than
clarify, overall system objectives
Elicitation & Analysis:
Problems

Understanding
◦ Customers/users are …
 Not completely sure of what is needed
 Have a poor understanding of the capabilities and limitations
of their computing environment
 Don’t have a full understanding of the problem domain
 Have trouble communicating needs to the system engineer
 Omit information that is believed to be “obvious,”
 Specify requirements that conflict with the needs of other
customers/users
 Specify requirements that are ambiguous or untestable
Elicitation & Analysis:
Problems

Volatility
◦ Requirements change over time
◦ Rate of change is sometimes referred to as
the level of requirement volatility
Guidelines
Assess the business and technical
feasibility for the proposed system
 Identify the people who will help specify
requirements and understand their
organizational bias
 Define the technical environment (e.g.,
computing architecture, operating system,
telecommunications needs) into which
the system or product will be placed

Guidelines
Identify "domain constraints" (i.e.,
characteristics of the business
environment specific to the application
domain) that limit the functionality or
performance of the system or product to
be built
 Define one or more requirements
elicitation methods (e.g., interviews, focus
groups, team meetings)

Guidelines
Solicit participation from many people so
that requirements are defined from different
points of view; be sure to identify the
rationale for each requirement that is
recorded
 Identify ambiguous requirements as
candidates for prototyping
 Create usage scenarios or use cases to help
customers/users better identify key
requirements

Sequence of steps

Problem pyramid: Six steps which must be
performed in sequence
Sequence of steps
1.
2.
3.
Identify the real
problem, opportunity
or challenge
Identify the current
measure(s) which
show that the
problem is real
Identify the goal
measure(s) to show
the problem has been
addressed and the
value of meeting it
4.
5.
6.
Identify the "as-is"
cause(s) of the
problem, as it is the
causes that must be
solved, not the
problem directly
Define the business
"whats" that must be
delivered to meet the
goal measure(s)
Specify a product
design how to satisfy
the real business
requirements
Complementary approaches









Identifying stakeholders
Modeling goals
Modeling context
Discovering scenarios (or Use cases)
Discovering "qualities and constraints" (Nonfunctional requirements)
Modeling rationale and assumptions
Writing definitions of terms
Analyzing measurements (acceptance criteria)
Analyzing priorities
Requirements Analysis
Encompasses those tasks that go into
determining the needs or conditions to
meet for a new or altered product, taking
account of the possibly conflicting
requirements of the various stakeholders,
such as beneficiaries or users
 An early stage in the more general activity
of requirements engineering

Requirements Analysis
Requirements Analysis
Eliciting requirements
 Analyzing requirements
 Recording requirements

Eliciting requirements

Task of identifying the various types of
requirements from various sources
including …
◦ Project documentation
(e.g. the project charter or definition)
◦ Business process documentation
◦ Stakeholder interviews

This is sometimes also called
requirements gathering
Analyzing requirements

Determining whether the stated
requirements are …
◦
◦
◦
◦
Clear
Complete
Consistent and unambiguous
Resolving any apparent conflicts
Recording requirements

Requirements may be documented in
various forms, usually including a
summary list and may include naturallanguage documents, use cases, user
stories, or process specifications
Stakeholders
Anyone who operates the system
(normal and maintenance operators)
 Anyone who benefits from the system
(functional, political, financial and social
beneficiaries)
 Anyone involved in purchasing or
procuring the system

Stakeholders




Organizations which regulate aspects of the
system (financial, safety, and other regulators)
People or organizations opposed to the
system (negative stakeholders; see also Misuse
case)
Organizations responsible for systems which
interface with the system under design
Organizations who integrate horizontally with
the organization for whom the analyst is
designing the system
Stakeholder Issues








Users do not understand what they want or users don't
have a clear idea of their requirements
Users will not commit to a set of written requirements
Users insist on new requirements after the cost and
schedule have been fixed
Communication with users is slow
Users often do not participate in reviews or are
incapable of doing so
Users are technically unsophisticated
Users do not understand the development process
Users do not know about present technology
Types of Requirements










Customer
Architectural
Structural
Behavioral
Functional
Non-functional
Performance
Design
Derived
Allocated Requirements