Lecture Requirement engineering Chapter 1 Introdution of software requirement

Lecture Requirement engineering Chapter 1 Introdution of software requirement. This chapter presents the following content Software life cycle process, what is requirement? Requirement engineering, types of requirements.

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:

 A phase = a series of steps, which rely upon

techniquesthat produce deliverables

28/4/2014 4

28/4/2014 6

28/4/2014 7

28/4/2014 8

28/4/2014 9

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

Inception Elaboration Construction Transition

time

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  Distribution of Effort to Fix

Defects

Code 7% Other

10%

Design 27%

Requirements

56%

Code 1% Other

14

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)

15

Requirements Engineering (RE) is:

The activity of development, elicitation,

specification, analysis, and management of

be met by a new or evolving system

RE is concerned with identifying the

purpose of a software system… and the

How/where the system will be used

Big picture is important

16

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?

17

RE

Requirement Development Management Requirement

Elicitation Analysis Specification Validation Reqruirement

Inception

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

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

 Verification: checks that the product is being

 During design phase: refers back to the

specification of the system or software

requirements

 During RE: mainly checking consistency between different requirements, detecting conflicts

Techniques used during RE

Simple checks

Formal Review

Logical analysis

Prototypes and enactments

Design of functional tests

Development of user manual

Requirement Management is to organize and manage of Requirements to ensure all

requirements are satisfactorily implemented and accepted

Software requirements include four distinct levels:

 Business requirements

 User requirements

 Functional requirements

 Non-Functional requirements

Business requirements

User requirements

Functional requirements

Non-functional requirements

 Represent high-level objectives of the

organization or customer who requests the

record the business requirements in a vision and

scope document, sometimes called a project

charter or a market requirements document

Describe user goals or tasks that the users

must be able to perform with the system

Valuable ways to represent user requirements include use cases, scenario descriptions, and event-response tables

An example of a use case: "Make a

Reservation" using an airline, a rental car, or a hotel Web site

Specify the software functionality that the developers must build into the product to enable users to accomplish their tasks

Describe what the system should do

What inputs the system should accept

What outputs the system should produce

What data the system should store other

systems might use

What computations the system should

perform

35

Example:

 The user shall be able to search either all of the

initial set of databases or select a subset from it

 Every order shall be allocated a unique identifier (ORDER_ID) which the user shall be able to copy to the account’s permanent storage area

A requirement that is not functional

Include many different kinds of requirements:

 Performance requirements

 Design constraints (also called process

requirements)

 Commercial constaints

Performance requirements

 characterize system properties such as expected performance, capacity, reliability, robustness,

usability, etc

 reflecting: usability, efficiency, reliability,

Design constraints (also called process

requirements)

 providing constraints on how the system should

be designed and built – related to development process, documentation, programming language, maintainability, etc

 Categories constraining the environment and

Platform (minimal requirements, OS, devices…)

Technology to be used (language, DB, …)

Commercial constaints: Categories

constraining the project plan and

development methods

 Development process (methodology) to be used

 Cost and delivery date

Often put in contract or project plan instead

Requirement Specification is a description of how a system should behave or a description

of system properties or attributes It can

alternatively be a statement of “what” an

application is expected to do