cs3773 software engineering lecture 02 requirements engineering

CS3773Software Engineering

Lecture 02 Requirements Engineering

UTSA CS37732

Requirements Engineering

Requirements engineering is usually the first stage of software life cycle

Requirements engineering is the process of understanding and defining functionalities and constraints of proposed systems

Requirements engineering process produces a document, software requirements specification (SRS) – Customers need a high level specification– Software designers and developers need a more detailed

specification

UTSA CS37733

Software Requirements

Requirements are desired behaviors– Customers “know” what the system shall do– Software engineers “know” what to built

“Requirements are means of communication with customer and many other stakeholders”

-- by Helene Wong, PhD thesis, 1994

Requirements deal with– Objects– States– Functions

UTSA CS37734

Software Requirements Stakeholders

Requirements analysts or system analysts determine requirements

Stakeholders contribute to requirements of systems– Clients– Customers– End-users– Software engineers– Domain experts– Lawyers or auditors– Market researchers

UTSA CS37735

Types of Requirements

Functional– What is the system supposed to do– Mapping from input to output

Non-functional (quality)– Usability– Performance– Security– Reliability– Maintainability– Portability

UTSA CS37736

Types of Requirements

Process constraints– Resources – Documentation – Standards

Design constraints– Physical environment– Interface– Users

UTSA CS37737

Requirements Are Important

The hardest single part of building a software system is

deciding precisely what to build. No other part of the

conceptual work is as difficult as establishing the

detailed technical requirements, including all interfaces

to people, to machines, and to other software systems.

No other part of the work so cripples the resulting

system if done wrong. No other part is more difficult to

rectify later.

-- by Frederick Brooks, “No silver bullet: essence and accidents of

software engineering”, 1986.

UTSA CS37738


80% of all software errors are requirements errors

– These are software errors detected after unit testing – i.e.,

in integration testing, in system testing, and after the

software is released

– Most errors can be traced to unknown, wrong, or

misunderstood requirements

UTSA CS37739


Requirements usually affect large portions of the

implementation; they are rarely encapsulated into

modules

Requirements errors may be fundamental assumptions

built into the design or code

Expensive requirements errors are often not fixed; they

become “features”

UTSA CS377310


Requirements errors are expensive to fix

Stage discovered Relative repair cost

Requirements 0.1 – 0.2

Design 0.5

Coding 1

Unit test 2

Acceptance test 5

Maintenance 20

UTSA CS377311

Requirements Problems

Over-specification Under-specification (unintended) Contradictory requirements Ambiguous requirements Unknown requirements Bad assumptions about environment Changing requirements

UTSA CS377312

Characteristics of Requirements

Correct Consistent Complete Concise Traceable Unambiguous Understandable Verifiable

UTSA CS377313

Requirements Engineering Process

Determine the requirements of a system, and specify

what behavior is realized– Work with customers to elicit the requirements

– Analyze and model the requirement

– Document the requirements in a software requirements

specification

– Validate the requirements specification

UTSA CS377314

Requirements Tasks

Understand problem from each stakeholder's point of

view

Extract the essence of the stakeholders' requirements

Negotiate a consistent set of requirements with

agreement from all stakeholders; set relative priorities

Record results in an SRS

UTSA CS377315

Requirements Elicitation

Elicitation is to gather– Functions that the system should perform

– Non-functional requirements that the system should

exhibit

Elicitation is critical but difficult– Customers are not good at describing what they want

– Software engineers are not good at understanding what

customers want

– Customers and software engineers speak different

languages

UTSA CS377316

Requirements Elicitation

Requirements analysts have to understand the

system from each stakeholder's point of view – Stakeholders have different views of the system

Requirements analysts resolve conflicting views

Requirements analysts prioritize requirements– Essential requirements– Desirable requirements– Optional requirements

UTSA CS377317

Elicitation Techniques

Understand problems

For existing system– Review documentation

– Observe current system

– Questionnaires and Interviews

– Apprenticeship

For new systems - brainstorming

UTSA CS377318

Analyze Existing System

What is used, what isn't, what's missing

What works well, what doesn't

How the system is used, how it was intended to be

used, what new ways we want it to be used

Risks– Users might not be happy with too much change from

the old system– Might miss real usage patterns– Might miss obvious possible improvements

UTSA CS377319

Analyze Existing System - Review

Review all available documentation– For an automated system, review its requirements

specifications and user manuals, as well as development

documentation, internal memos, change histories, etc.

– For a manual system, review any documented

procedures that the workers must follow

Gain knowledge of the system before imposing upon

other people's time, before bothering the

stakeholders

UTSA CS377320

Analyze Existing System - Observation

Identify what aspects to keep and to understand the

system you are about to change

System contains a lot of useful functionality that

should be included in any future system

Documentation rarely describes a system completely

and not up to date and

Current operation of the system may differ

significantly from what is described

UTSA CS377321

Analyze Existing System - Interview

Questionnaires are useful when information has to be

gathered from a large number of people

The answers to questions need to be compared or

corroborated.

Ask problem-oriented questions during interview

Interview groups of people together to get synergy

UTSA CS377322

Analyze Existing System - Apprentice

The requirements analyst is the apprentice and the

user is the master craftsman.

The user can– Describe the task precisely– Explain why the task is done this way– List the exceptions that can occur

UTSA CS377323

Brainstorm

Brainstorm is used to gather ideas from every

stakeholder and prune ideas

When you have no idea, or too many ideas, sit down

and thrash it out, but with some ground rules

Most useful early on, when terrain is uncertain, or

when you have little experience, or when novelty is

important

UTSA CS377324

Brainstorm

Keep the tone informal and non-judgmental

Encourage creativity

Keep the number of participants “reasonable”, if too

many, consider a “playoff”-type filtering

Invite back most creative to multiple sessions

UTSA CS377325

Brainstorm - the Storm

Generate as many ideas as possible

Quantity, not quality, is goal at this stage

No criticism or debate is permitted

Write down all ideas where all can see

Participants should NOT self-censor or spend too

much time wondering if an idea is practical

Original list does not get circulated outside of the

meeting

UTSA CS377326

Brainstorm – the Calm

Go over the list and explain ideas more carefully

Categorize into “maybe” and “no” by pre-agreed

consensus method

Be careful about time

Meetings tend to lose focus after 90 to 120

minutes

Review, consolidate, combine, clarify, and expand

Rank the list by priority somehow; choose a winner

UTSA CS377327

Brainstorm – Pruning

Vote with threshold– Each person votes up to n times

– Keep those ideas with more than m votes

– Have multiple rounds thereof with smaller n and m

Vote with campaign speeches– Each person votes up to j < n times

– Keep those ideas with at least one vote

– Have multiple rounds thereof with smaller j

UTSA CS377328

Requirements Analysis

Understand the desired behavior

– Interpret the stakeholders' descriptions of requirements

– Resolve ambiguities, contradictions, loose ends, etc.

Build models– Use standard notations

– Help us to understand the requirements

UTSA CS377329

Requirements: What vs. How

Requirements describe purpose and scope of the

system– What behavior the customer wants– Not how the behavior is realized

Requirements focus on customer and problems – Understand the customer’s needs– Describe the background and overview of the problem

Requirements represent objects, states, and functions Requirements include assumptions of the environment

UTSA CS377330

Requirements Specification

Specify requirements– Document what is required of the system to be developed– State the requirements from the perspective of the

developers – May be a formal document (IEEE-SRS)

Requirements document and specification document are

different– Requirements document is a contract– Specification is a detailed guideline for developers

UTSA CS377331

Requirements vs. Specification

Requirements document is– A complete list on what customers want– In terms of environment without reference to system– A contract between clients and developers

Specification represents– System’s behavior in terms of the input and output of a

system– Which requirements shall be realized by the system– How environment entities are controlled by the system

UTSA CS377332

Environment

Requirements Data structuresand algorithms

SystemInterface

Specification


UTSA CS377333

Requirements are a collection of statements about

phenomena in the environment that we want the

system to help make true

A specification is a collection of statements that

describe a system’s external behavior as observable

through the Interface– A specification refers only to shared phenomena in the

interface and what the system shall do

– A specification can constrain only shared phenomena

that the system itself can control


UTSA CS377334


Example: a turnstile to the park– Requirements

1. No one should enter the park without paying an entrance fee

2. For every entrance fee paid, the system should not prevent a corresponding entry

– Specification

When a visitor applies a certain amount of force on an

unlocked turnstile, the turnstile will rotate till a locked

position

UTSA CS377335

Requirements Validation

Validate the requirements against stakeholders– Reflect accurately customer’s need

– Also create system-level test plans

Validation can be done with techniques– Walkthrough

– Review

– Prototype

– Formal inspection

UTSA CS377336

Specification Verification

Verify the specification against requirements– Conforms to the requirement definition

– Build the system right

Verification can be done with techniques– Simulation

– Consistency checking

– Completeness checking

– Formal verification: model checking or mathematical

reasoning

UTSA CS377337

Software Requirements Specifications

Introduction

Overall description

Specific requirements

Requirements table

UTSA CS377338

Software Requirements Specification

Section 0– Table of Contents

Essential for tracing through use cases, classes, state

diagrams

– Table of Figures

Essential for finding each diagram

– List of Tables

Essential for finding each table

UTSA CS377339


Section 1 Introduction

1.1 Purpose of the SRS

e.g., the intended audience

1.2 Scope

1.3 Acronyms, abbreviations, notational conventions

1.4 Overview

e.g., the structure of the rest of the SRS document

1.5 ReferencesCan be put at the end of the document

UTSA CS377340


Section 2 General description

2.1 Product perspective – the environment

Any hardware and software components that interact

with the system

Overview of the interfaces to other component

A block diagram would be nice

UTSA CS377341



2.2 Product functions

Overview of the system’s main functions

No detail description

At the level of use case names

2.3 User characteristics

Assumptions about the user

UTSA CS377342



2.4 General constraints

e.g., laws, hardware limitations

Any sources of constraints on requirements or design

2.5 Assumptions and Dependencies

Assumptions about the environment

Any environmental conditions that could cause the system to fail

UTSA CS377343


Section 3 Specific requirements

3.1 Functional requirements

3.1.1 Use case diagrams and detail description in tabular format

Number each use case for future reference.

3.1.2 Class diagrams

3.1.3 State diagrams

3.1.4 Sequence diagrams

In each above section 3.1.x, give English introduction to each

diagram to help the reader understand each diagram.

UTSA CS377344


Section 3 Specific requirements (continued)

3.1 Functional requirements (continued)

3.1.5 Data dictionary in tabular format Classes: purpose Attributes: purpose, range of values Operations: purpose, parameters, pre/post conditions Events: purpose, source, destination, parameters

UTSA CS377345



3.2 User interface requirements Screen shots Purpose of each button, menu options, etc. List of input/output events How to navigate among windows

UTSA CS377346



3.3 Non-functional requirements

Reliability

Portability

Security

…

UTSA CS377347


Section 4 Requirements table– Requirement number– Name– Description– Related requirements’ numbers and source– Related use cases’ numbers

UTSA CS377348

Reading Assignments

Sommerville’s Book, 8th edition– Chapter 7, “Requirements Engineering Process”

Sommerville’s Book, 9th edition– Chapter 4, “Requirements Engineering”

IEEE Std 830-1998, “IEEE Recommended Practice for Software Requirements Specification”

cs3773 software engineering lecture 02 requirements engineering

Documents

requirements engineering

misunderstood requirements

important requirements

modules requirements

utsa cs3773

software errors

software systems

detailed specification