1211501075 Christian Yonathan Sillueta

Overview
Describe requirement engineering activities
and processes.
Look into techniques, problems, challenges of:
Feasibility Studies
Requirements elicitation
Requirement specification
Requirements Validation
Requirements management and evolution
Importance of Requirements
Making design decisions without understanding
all the constraints on the system to be developed
results in a system which fails to meet customers
expectations
Costs of correcting errors increases as the design
process advances.
An error detected in the maintenance phase is 20
times as costly to fix as an error detected in the
coding stage.
Cumulative effects of error
The Basics
A requirement mandates that something be
accomplished, transformed, produced or
provided
Requirements engineering is the discipline
concerned with understanding the externally
imposed conditions on a proposed computer
system, determining what capabilities will meet
these imposed conditions and and documenting
those capabilities as the software requirements
for the computer system.
Requirements Engineering Process
The processes used for RE vary widely
depending on the application domain, the
people involved and the organisation
developing the requirements
Requirements Elicitation
Requirements Analysis
Requirements Specification Requirements Verification
Requirements Management
Requirements Engineering
Requirements Elicitation
Requirements Analysis
Requirements Specification Requirements Verification
Requirements Management
Requirements Engineering
Requirements Engineering Process
Requirements elicitation : The process through which
clients and developers review, articulate and
understand the needs of the clients and the constraints
on the software
requires involvement with the client, domain experts,
and end-users in order to establish an the clients needs
and the constraints on the system. Here we use
techniques such as: (1) Interviews, (2) Questionnaires,
(3) Focus groups, (4) Apprenticing, and (5) modelling.
Requirements Engineering Process
Requirements Analysis : The process of analysing the
needs of the clients in order to arrive at a definition of
the requirements
aims to deepen our understanding of the constraints
and client needs
Requirements Specification : The process by which a
document is developed which clearly communicates the
requirements.
The requirements are captured, or expressed, or
articulated, in a software requirements specification.
Requirements Engineering Process
Requirements Validation : The process of ensuring that
the requirements and the Software Requirements
Specification are in compliance with the needs of the
clients and the system
techniques here include (1) reviews, inspections and
walkthroughs of requirements, and (2)prototyping.
Requirements Management and evolution : The
planning and controlling of the requirements
engineering processes. Requirements specification
should evolve with time.
Feasibility Study
Feasibility
Feasibility studies aim to objectively and rationally
Uncover the strengths and weaknesses of the existing
business or proposed venture
Opportunities and threats as presented by
the environment.
The resources required to carry through.
Ultimately the prospects for success of the proposition
In its simplest term, the two criteria to judge
feasibility are cost required and value to be attained.
Types of Feasibility
The assessment is based on an outline design of
system requirements in terms of Input, Processes,
Output, Fields, Programs, and Procedures.
Technological feasibility
carried out to determine whether the company has the
capability, in terms of software, hardware, personnel and
expertise, to handle the completion of the project
when writing a feasibility report, the following should be
taken to consideration:
A brief description of the business
The part of the business being examined
The human and economic factor
The possible solutions to the problems
Types of Feasibility
Economic analysis
used method for evaluating the effectiveness of a new system. More
commonly known as cost/benefit analysis, the procedure is to determine the
benefits and savings that are expected from a candidate system and compare
them with costs. If benefits outweigh costs, then the decision is made to
design and implement the system.
Cost-based study:
It is important to identify cost and benefit factors, which can be categorized
as follows:
1. Development costs
2. Operating costs.
This is an analysis of the costs to be incurred in the system and the benefits
derivable out of the system.
Time-based study:
This is an analysis of the time required to achieve a return on investments.
The future value of a project is also a factor.
Types of Feasibility
Legal feasibility
Determines whether the proposed system conflicts with legal requirements,
e.g. data processing system must comply with the local Data Protection
Acts.
Operational feasibility
Operational feasibility is a measure of how well a proposed system solves
the problems, and takes advantage of the opportunities identified during
scope definition and how it satisfies the requirements identified in the
requirements analysis phase of system development.
Schedule feasibility
A project will fail if it takes too long to be completed before it is useful.
Typically this means estimating how long the system will take to develop,
and if it can be completed in a given time period using some methods
like payback period. Schedule feasibility is a measure of how
reasonable the project timetable is. You need to determine whether
the deadlines are mandatory or desirable.
Types of Feasibility
Financial feasibility
In case of a new project, financial viability can be judged on the
following parameters:
Total estimated cost of the project
Financing of the project in terms of its capital structure, debt equity ratio and
promoter's share of total cost
Existing investment by the promoter in any other business
Projected cash flow and profitability
Other feasibility factors:
Market and real estate feasibility
Resource feasibility
Cultural feasibility
Requirements Elicitation
Requirements Elicitation is the process of discovering the
requirements for a system by communication with
customers, system users and others who have a stake in the
system development.
Elicitation
The Yes, But syndrome
The Undiscovered Ruins
User and Developer syndrome
The sins of your predecessors
Challenges of Requirements
Elicitation
The Yes, But syndrome
First time users see the system the first reaction is
either, wow this is so cool or Yes, but, hmmmmm,
now that I see it, what about this? Wouldnt it be
nice ?
Anticipate that there will be yes, buts and add time
and resources to plan for feedback.
Tends to be User Interface centric, these tend to be
the touch points of the system by the users.
The Undiscovered Ruins
syndrome
Teams struggle with determining when they are
done with requirements elicitation.
Is done when all the requirements are elicited or
have they found at least enough?
Like asking an archeologist how many
undiscovered ruins are there?
The User and the developer
syndrome
Users do not know what
they want, or they know
what they want but
cannot articulate it.
Users think they know
what they want until
developers give them
what they said they
wanted.
Analysts think they
understand user
problems better than
users do.
Recognize and appreciate
the user as domain
experts; try different
techniques.
Provide alternative
elicitation techniques
earlier; storyboard, role
playing, prototypes, and
so on.
Put the analyst in the
users place. Try role
playing for an hour or a
day.
Characteristic Characteristic Response Response
The living with the sins of your
predecessors syndrome
Like it or not your users (marketing) and developers
remember what happened in the past.
Quality programs that promised things would be different.
The last project where requirements were vague and/or
were delivered short of expectations.
Need to build trust, slowly. Do not over commit to features,
schedule, or budget.
Build success by delivering highest priority features early in
the process.
The Requirements Elicitation
techniques
Interviewing and questionnaires
Requirements workshops
Braining Storming and idea reduction
Use Cases
Role Playing
Prototyping
EX:
Summary
Interview : Context Free Question
Goal is to prevent prejudicing the users response to the
questions.
Examples:
Who is the user?
Who is the customer?
Are their needs different?
Where else can a solution to this problem be found?
Context-free questions
After context-free questions are asked, suggested solutions
can be explored.
Interview : Show Time
Establish Customer or User Profile
Assessing the Problem
Understanding the User Environment
Recap the Understanding
Analysts Inputs on Customers Problems
Assessing Your Solution (if applicable)
Technique : Requirement
workshop
It gathers all key stakeholders together for a
short but intensely focused period.
The use of an outside facilitator experienced
in requirements management can ensure the
success of the workshop.
Brainstorming is the most important part of
the workshop.
Technique : Role Playing variant
on use cases
Role playing allows stakeholders to experience
the users world from the users perspective.
A scripted walkthrough may replace role playing
in some situations, with the script becoming a
live storyboard.
(Class-Responsibility-Collaboration (CRC) cards,
often used in object-oriented analysis, are a
derivative of role playing.)
Requirements Analysis & Specification
Analysis & Specification
Requirements analysis :
The process of studying and analysing the
customer and the user/stakeholder needs to arrive
at a definition of software requirements
Requirements Specification:
o A document that clearly and precisely describes
essential requirements of software and external
interfaces (functions, performance, quality etc.)
o each requirement is specified such that its
achievement is capable of being verified by a
prescribed method like inspection, test.
Analysis of Elicitation Results
Analysis of the results of elicitation process helps to
create a better vision of the product and its
specification by:
Explaining the problem statement better
Marketing group establishes positioning of the
product
Stakeholder and user summaries
o user is special case of stakeholder
o identify stakeholder w.r.t development
o identify stakeholder w.r.t system
The precision to which Requirements are
specified is a function of
Expertise of developers
Knowledge developers and testers have of the
domain the more they know, the less specific the
specification needs to be
Access to a domain representative
For example, in xp, requirements may be specified in
less detail but there is a customer representative on site
daily.
Requirement Specification
Requirements Perspectives
User requirements
Statements in natural language plus diagrams of the
services the system provides and its operational
constraints. Written for customers.
System requirements
A structured document setting out detailed
descriptions of the systems functions, services and
operational constraints. Defines what should be
implemented so may be part of a contract between
client and contractor.
Types of Requirements
Functional requirements :
Statements of services, how the system should react to
particular inputs, what functionalities is to be provided.
Functional requirements are not concerned with how these
functions are to be achieved, just what is to be achieved.
Non functional requirements:
deals with attributes, or properties, of the software
rather than functions. We include here aspects of the
software such as its performance, its usability, its reliability,
any safety aspects and a range of other attributes.
Domain Requirements:
Requirements of the application domain of the system,
reflect characteristics of that domain.
Requirements Characteristics
Unambiguous
Testable (verifiable)
Clear (Concise, terse, simple, precise)
Correct
Understandable
Feasible
Independent
Atomic
Necessary
Implementation free (abstract)
Requirements Characteristics
Besides the criteria for individual
requirements, 3 criteria should apply to the
set of requirements as a whole:
Consistent
Non redundant
Complete
The Output
A Software Requirements Specification (SRS) A formal
Document as the OUTPUT of the Specification stage.
it is a complete description of the behavior of a system to be
developed.
INCLUDES:
Functional Requirements
Non- Functional Requirements
Constraints
Design Strategy
Quality and Standards
Architecture
Development Methodology
Sequence Diagram
ATM Database
Card
Card number
Card OK
PIN request
PIN
Option menu
<<exception>>
invalid card
Withdraw request
Amount request
Amount
Balance request
Balance
<<exception>>
insufficient cash
Debit (amount)
Debit response
Card
Card removed
Cash
Cash removed
Receipt
Validate card
Handle request
Complete
transaction
Activity Diagram
Data Flow Diagram
Validation
Requirements Validation
Validation:
ensures that the software being developed will satisfy it
stakeholders
Requirements Validation checks the software
requirements specification against stakeholders
goals and requirements
Verification:
ensures that each step followed in the process of building the soft
ware yields the right products
Requirements Verification checks the consistency of
the software requirements specification artifacts and other
Software development products (design, implementation, ...) again
st the specification
Typical Requirements V&V
approaches
Tracing approaches
Prototyping
Testing
User manual writing
Formal validation
Reviews and inspections
Walkthroughs
Formal inspections
Checklists
Requirements Management and Evolution
Definition
Requirements management is the process of
documenting, analyzing, tracing, prioritizing and agreeing on
requirements and then controlling change and communicating to
relevant stakeholders.
It is a continuous process throughout a project.
A requirement is a capability to which a project outcome (product
or service) should conform.
Requirements Pyramid
CASE Tools
IBM Rational DOORS
Requirements management, traceability, and impact analysis
capabilities for more formal, rigorous requirements engineering
purposes, primarily suited to organizations creating manufactured
systems and products
IBM Rational Requirements Composer
Helps teams to define requirements more effectively and manage them
efficiently across the project lifecycle to gain better business outcomes
through light-weight requirements practices
IBM Rational RequisitePro
Requirements management, traceability, and impact analysis
capabilities for project teams, primarily suited to organizations creating
application software
Software Evolution
The priority of requirements from different
viewpoints changes during the development
process.
System customers 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.
Classification for changing
requirement
Enduring requirements. Stable requirements
derived from the core activity of the customer
organisation.
Volatile requirements. Requirements which
change during development or when the
system is in use.
Classification for changing
requirement
Enduring requirements. Stable requirements
derived from the core activity of the customer
organisation.
Volatile requirements. Requirements which
change during development or when the
system is in use.
Requirements Traceability
Requirements traceability is concerned with documenting the
life of a requirement.
It should be possible to trace back to the origin of each
requirement
and
Every change made to the requirement should therefore be
documented in order to achieve traceability.
Even the use of the requirement after the implemented features
have been deployed and used should be traceable
[4]
.