Are the requirements

addictedswimmingΤεχνίτη Νοημοσύνη και Ρομποτική

24 Οκτ 2013 (πριν από 3 χρόνια και 9 μήνες)

72 εμφανίσεις

Requirements Engineering


Chapter 6 in
Essentials of Software Engineering,
T
hird Edition






Sheryl Duggins

What are Requirements?




A requirement is a feature of the system or description of
something the system is capable of doing in order to fulfill
the
system’s purpose.



It specifies the purpose of
system (
what
it’s supposed to do)
without specifying
how
it is to be built.


Goal of Requirements Analysis: determine nature of
customer’s problem



Types of Requirements



Two
kinds of requirements exist:


1. Functional Requirements


describe
what
the system
should
do
given certain stimuli


2. Nonfunctional Requirements (or Performance
Requirements)


constraints that describe restrictions on
system that limit our choices for constructing solution


So how important are requirements and
what happens if we mess them up?

The
Standish Group Report 1998 indicated:


26% of projects are successful


46% are challenged


28% failed


Why is this happening?
The
Standish Group said 5
top reasons
are related to requirements:


Incomplete requirements


Lack of user involvement


Unrealistic customer expectations


Changing requirements and specifications


No longer need the capabilities provided


A
comment from one of the Standish Group participants
:



“If you don’t nail the requirements, you fail the project. If you nail the
requirements, you’ll deliver
.”


One of the top reasons
for
project success is good requirements.





Preparation for Requirements Engineering

Plan

For

Requirements

Activities

Agreeing on

resources,

methodology
and

schedule

for

Requirements

Activities

Obtain and

organize the

agreed upon

resource and

methodology

1. Prior to actually performing the requirements engineering activities,

it is important to
plan for the resources, methodology and time needed

to

perform this crucial step in software engineering.


2. Some organizations even perform requirements engineering
as a separate ,

stand
-
alone activity and price it separately
, with the option of folding the cost

Into the whole project if they get the call to complete the software project.

Major Requirements
Engineering
Process Activities


Requirements elicitation


Requirements discovered through consultation with stakeholders


Requirements analysis and negotiation


Requirements are analyzed and conflicts resolved through negotiation


Requirements documentation


A

requirements document is produced


Requirements validation


The requirements document is checked for consistency and completeness

Requirements Engineering Process
Model

Requirements Engineering Activities

Requirements

Elicitation

Requirements

Analysis&

Negotiation

Requirements

Definition

Requirements

Prototyping

Requirements

Validation

Requirements

Specification

Requirements

Agreement &

Acceptance

-

Red color represents direct user/customer involvement

Documentation

Documentation

Why is
T
his Set of Activities
I
mportant and Why
S
hould
R
equirements be Documented?


Clear requirements
are needed
for
design

and
implementation

activities.


Requirements
documentation

is needed
to
create test cases
and
test scenarios

-

-

-

especially for large systems where the test team
is a separate group of people from the developers.


Requirements
documentation
is needed
to
control potential
scope
-
creep
.


Requirements
document
is needed
to create
user training

material, marketing material, and documents for design, support
and maintenance.


Requirements
document

provides a way
to
segment a large
project
, prioritize releases , and simplify project management

Requirements Elicitation


Requirements:


May be
given

to the software engineers


Initial product/system requirements


For second and/or third follow
-
on release of a “planned” sequences
of software product where a preliminary set of requirements are
already established


Requirements provided as a part of a request for price quotation for
a software development project



Have to be
established

by software engineers


Users sometimes have an understanding of only the requirements
related to their specific job tasks


The business rationale and goals are not always clear to individual
user and needs to be established for prioritization reason


There may be contradicting and incomplete requirements stated by
the users and customers




High Level Requirements Elicitation


Need to seek out the
business and management perceptions and goals
for the software project


Business opportunity and business needs


Justification for the project


Scope


Major constraints


Major functionality


Success Factor


User characteristics

Software Engineers who have to interact with business
management and
handle
requirements are sometimes called
Business Analysts

6
-
Dimensions of
Detailed

Requirements Elicitation

Requirements

Individual Functionality

Business Workflow

Data and Data formats

User Interfaces

Existing & Systems Interfaces

Other Constraints: Performance,

Reliability, etc.

Requirements Analysis


Requirements “
analysis
” is composed of:



Categorizing and organizing the requirements


Prioritizing the requirements



Also “
start to look”
for
consistency & completeness


Requirements Classification/Categorization


Most
High Level
:


Functional


Non
-
functional



Other more
detailed groupings
also exist


6 dimensions of requirements


Requirements
Categorization


By detailed 6 requirements areas:


1.
Individual functionality

2.
Business flow (usage ‘scenarios’)

3.
Data and information needs

4.
User interfaces

5.
Other interfaces to external systems/platforms

6.
Various constraints (non
-
functional)


Performance


Security


Reliability


etc.



Requirements Prioritization


Most of the time we have some limitations in developing
software:



Time


Resources


Technical capabilities (existing)



We need to
prioritize

the requirements to satisfy these
limitations

Requirements Priorities


Requirements prioritization is an
activity of comparing the
requirements and placing them in some order relative to each other.


Some Criteria for prioritization:


Current user/customer
demands

or
needs


Competition and current
market condition


Anticipated future and new customer
needs


Sales
advantages


Existing critical problems in current product


These are often subjective and requirements should be
prioritized with the help of many of the stakeholders
(different viewpoints).



A Simple Requirements Prioritization List “sample”

Req. #

Brief Req.

description

Req. source

Req. priority

Req. Status

# 1

One page

query must

respond in

less than

1 second

A Major

account

Marketing

Rep.

Priority 1
*

Accepted for

this release

# 2

Help text

must be

field sensitive

Large account

users

Priority 2

Postponed

For next

release

* Priority may be 1, 2, 3, or 4, with 1 being the highest

Requirements
Definition/Prototyping/Validation


Once the requirements are solicited, analyzed and
prioritized, more details must be spelled out. Three
major activities which may be intertwined must be
performed:



Requirements definition


Requirements prototyping


Requirements validation

Requirements Definition and Documentation


Requirements document (the analysis document)
: consists of a
precise description of the problem domain together with the
requirements


Requirements
are written in natural language (e.g., English) and are
uniquely identified; they typically are written as: “The system shall …”
and are often called “shall statements”


Specification
: contains a definition of the required behavior of the
solution system; also known as RS, SRS,RD; forms the basis of the
formal contract
between client and
developer


Sometimes Requirements Definition and SRS may include additional
diagrams:

1.
Simple Input/Process/Output (I
-
P
-
U) descriptions in English

2.
Dataflow diagrams (DFD)

3.
Entity Relations diagram (ERD)

4.
Use Case Diagram from Unified Modeling Language (UML)


Once the requirements are defined in detail they still need to be
validated

(see chapter 10 of your textbook)
by the users/customers
and other stakeholders.


Requirement Definition using English and

Input
-
Process
-
Output Diagram Form

Req. #

Input

Output

Process

# 12:
Customer

Order Entry

-

Items

by type


and quantity

-
Submit
request


of items

-

Accept

the


items and


respective


quantities/


include error


and rejection


of items

-

Display


“acceptance”


message and

-

Ask

for


confirmation


message

English I/P/O : functionality, business and data fl
ow

Syntax of Data Flow Diagram (DFD)

Customer

Process XXX

Ordered Data

symbols

semantics

source or destination of data

process or function

data store/file

flow of data

Requirements
E
xpressed
U
sing DFD

Orders

Order Processing

Customer Info DB

Customer credit,

address, etc.

Inventory Info.

Packaging

Invoice

Product

avail.

Info.

Package Data

Packaging

details

Shipping

Instruct.

Customer


Captures


functionality, business flow, data

Requirements Expressed using Entity
-

Relation
-
Diagram (ERD)

order

items

includes

1

m

Cardinality
:

specifies the
number of occurrences

of entities

customer

order

Modality
:

specifies the
necessities of relationship

to exist

Captures
-

relations among data

Requirements Expressed Using

Entity and
Attributes

Employee

Address

Name

Age

Street


City


State


Zip

(a) Graphical form

(a) Tabular form

Employee

-

Name

-

Address

-

Age

-

Street

-

City

-

State

-

Zip

Captures
-

relations among data

Requirements Traceability


Capability to trace a requirements is needed to ensure that the
product has fully implemented (i.e., not “lost” or “gained” any) the
requirements. (It is an important part of the requirements
process.)



We need to trace requirements:


Requirements
from

source (people and documents)


Requirements
to

later steps
(use cases, design, implementation, test, &
final system)



We also need to
link

requirements to other related requirements.

Partially Filled Traceability Table

Requirement

Design

Code

Test

Other related

requirements


1

comp. X


Module 3

Test Case 32


2, 3


2

comp. Y


Module 5

Test Case 16


1


3

comp. Z


Module 2

Test Case 27


1


4


5


6


7

Software Validation


Validation attempts to ensure that the correct functionality
for the solution system has been defined.


Need to validate the entire RE process (and the entire SWE
process as well) to check:


Is the description of the problem domain an accurate reflection of
its properties?


Are the requirements (the effects to be produced in the problem
domain) accurately recorded?


Is the external design correct; will the invented behavior of the
new system
produce
the required effects?


Is the specification an accurate reflection of the intended
external design?


Requirements Prototyping


Requirements prototyping is primarily used to validate the
requirements.


The prototyping may be performed in one or both of the
following modes:


Low fidelity (also called Paper Prototype)

: using
paper/cardboard to represent screens and including
arrows and screen numbers/pages to represent the screen
flow


High fidelity (also called Prototype)

: using automated
tools such as Visual Basic to code the screens and direct
the logical flow of these screens

Requirements
Document
S
tructure


IEEE/ANSI 830
-
1998 standard proposes a structure for
software requirements documents


Introduction

1.1 Purpose of requirements document

1.2 Scope of the product

1.3 Definitions, acronyms and abbreviations

1.4 References

1.5 Overview of the remainder of the document

Requirements
Document Structure
Cont.


2.

General description

2.1 Product perspective

2.2 Product functions

2.3 User characteristics

2.4 Constraints

2.5 Assumptions and dependencies


3.

Specific requirements


Covering functional, non
-
functional and interface
requirements.


Appendices


Index


Finally
---

Requirements “Sign Off”


Having a requirements specification agreed to and signed off
is important:



Serves as a milestone marker and a
formal contract

between the software engineers and the client


Serves as
baseline
from which any future changes can be
monitored and controlled