Lecture Requirement engineering Chapter 1 Introdution of software requirement

 Software

Life Cycle Process
 What is Requirement?
 Requirement Engineering
 Types of requirements


 [1]

Ralph R. Young - The Requirements
Engineering Handbook- 2004 Artech House, Inc.
 [2] Karl E. Wiegers, Software requirement, Second
Edition- Microsof t Press © 2003(ebook)
 [3] Brian Berenbach, Daniel J. Paulish, Juergen
Kazmeier, Arnold Rudorfer - Software & Systems
Requirements Engineering: In Practice- Mc
GrawHill, 2009
 [4] Ian Alexander, Ljerka Beus-Dukic – Discovering
Requirements - John Wiley and Sons, Ltd.,
Publication


 Systems

development life cycle (SDLC)

The series of steps used to mark the phases of

development for an information system.

 The SDLC has a set of five fundamental phases:
Planning
Analysis
Design
Implementation
Test
 A phase = a series of steps, which rely upon
techniquesthat produce deliverables
28/4/2014

4


 Structured

design

Waterfall
Parallel Development
 RAD

Phased Developmen
Prototyping
 RUP
 Agile

Development

extreme programming (XP),
Scrum

Dynamic Systems Development Method (DSDM).

28/4/2014

5


28/4/2014

6


28/4/2014

7


28/4/2014

8


28/4/2014

9



Inception

Elaboration

Construction

Transition

time

 RUP

has 4 phases:
Inception (Khởi đầu)
Elaboration (Triển khai)
Construction (Xây dựng)
Transition (Chuyển giao)
 Each phase ends at a major milestone and
contains one or more iterations


 Requirement

is something wanted or

needed.
 Hence, requirements on particular
system/application are typically a complex
combination of requirements from different
people at different levels of an organization
and from the environment in which the
software will operate.



Distribution of Defects

Requirements
56%

Code
7%



Other
10%

Design
27%
Source: Martin & Leffinwell

Distribution of Effort to Fix
Defects

Requirements
82%

Code
Other
1%

4%

Design
13%


 Why

combining RE with modeling ?

For analysis – models help to understand

the

problem domain
For documentation – models can be used for
describing requirements (instead of solely using
natural language)

14


Requirements

Engineering (RE) is:

The activity of development, elicitation,

specification, analysis, and management of
the stakeholder requirements, which are to

be met by a new or evolving system.
RE is concerned with identifying the
purpose of a software system… and the
contexts in which it will be used
How/where the system will be used
Big picture is important
15


Requirements

Engineering (RE):

Captures real world needs of stakeholders

affected by a software system and expresses
them as artifacts that can be implemented
by a computing system
Bridge to design and construction
How to communicate and negotiate?
Is anything lost in the translation between
different worlds?
16


RE

Reqruirement
Inception

Elicitation

Requirement
Development

Analysis

Requirement
Management

Specification

Validation

17


 Indentify

business need  Build a business

case
 Preliminary feasibility assessment
 Preliminary definition of project scope
 Identify the stakeholders
 Recognize multiple viewpoints
 Work toward collaboration
 Break the ice and initiate the communication

 Requirement

Development includes all the
activities involved with gathering, evaluating,
and documenting the requirements for a
software or software-containing product.


 Eliciting

requirements is difficult because of

Project scope and purpose

in identifying the
boundaries of the system or specifying too much
technical detail rather than overall system
objectives
Problems of understanding what is wanted, what
the problem domain is, and what the computing
environment can handle (Information that is
believed to be "obvious" is often omitted)
Problems of volatility because the requirements
change over time


 Overview

of different techniques

Brainstorming
Interviews
Task observations

Use cases / scenarios
Prototyping
More ...


 Analyse,

refine, scrutinize the gathered
requirement
 Detect and resolve conflicts between
requirements  make consistent and
unambiguous requirements
 Discover the bounds of the software and how
it must interact with its environment


 Requirements,

once elicited, modeled and
analyzed should be documented in clear,
unambiguous terms.

 Developing

Software Requirement
Specification, focus of the project moves

from the broad statement of user needs, goals
and objectives, target markets and features of
the system to the details of how these eatures
are going to be implemented in the solution.


 Requirement

must be validated to ensure

that
The

software engineer has understood the
requirements  delivery of what the client wants
Requirements document conforms to
organizational standards
Different stakeholders, including representatives of
the customer and developer, shall review the
document


Validation: checks that the right product is
being built
 Verification: checks that the product is being
built right


 During design phase: refers back to the

specification of the system or software
requirements
 During RE: mainly checking consistency between
different requirements, detecting conflicts