Cs3773 software engineering
Download
1 / 48

CS3773 Software Engineering - PowerPoint PPT Presentation


  • 181 Views
  • Uploaded on

CS3773 Software Engineering. Lecture 02 Requirements Engineering. 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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' CS3773 Software Engineering' - jada


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Cs3773 software engineering

CS3773Software Engineering

Lecture 02

Requirements Engineering


Requirements engineering
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 CS3773


Software requirements
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 CS3773


Software requirements stakeholders
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 CS3773


Types of requirements
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 CS3773


Types of requirements1
Types of Requirements

  • Process constraints

    • Resources

    • Documentation

    • Standards

  • Design constraints

    • Physical environment

    • Interface

    • Users

UTSA CS3773


Requirements are important
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 CS3773


Requirements are important1
Requirements Are Important

  • 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 CS3773


Requirements are important2
Requirements Are Important

  • 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 CS3773


Requirements are important3
Requirements Are Important

  • Requirements errors are expensive to fix

UTSA CS3773


Requirements problems
Requirements Problems

  • Over-specification

  • Under-specification (unintended)

  • Contradictory requirements

  • Ambiguous requirements

  • Unknown requirements

  • Bad assumptions about environment

  • Changing requirements

UTSA CS3773


Characteristics of requirements
Characteristics of Requirements

  • Correct

  • Consistent

  • Complete

  • Concise

  • Traceable

  • Unambiguous

  • Understandable

  • Verifiable

UTSA CS3773


Requirements engineering process
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 CS3773


Requirements tasks
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 CS3773


Requirements elicitation
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 CS3773


Requirements elicitation1
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 CS3773


Elicitation techniques
Elicitation Techniques

Understand problems

  • For existing system

    • Review documentation

    • Observe current system

    • Questionnaires and Interviews

    • Apprenticeship

  • For new systems - brainstorming

UTSA CS3773


Analyze existing system
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 CS3773


Analyze existing system review
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 CS3773


Analyze existing system observation
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 CS3773


Analyze existing system interview
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 CS3773


Analyze existing system apprentice
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 CS3773


Brainstorm
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 CS3773


Brainstorm1
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 CS3773


Brainstorm the storm
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 CS3773


Brainstorm the calm
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 CS3773


Brainstorm pruning
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 CS3773


Requirements analysis
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 CS3773


Requirements what vs how
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 CS3773


Requirements specification
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 CS3773


Requirements vs specification
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 CS3773


Requirements vs. Specification

Specification

Data structures

and algorithms

Requirements

Interface

Environment

System

UTSA CS3773


Requirements vs specification1
Requirements vs. Specification

  • 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 CS3773


Requirements vs specification2
Requirements vs. Specification

  • Example: a turnstile to the park

    • Requirements

      • No one should enter the park without paying an entrance fee

      • 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 CS3773


Requirements validation
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 CS3773


Specification verification
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 CS3773


Software requirements specifications
Software Requirements Specifications

  • Introduction

  • Overall description

  • Specific requirements

  • Requirements table

UTSA CS3773


Software requirements specification
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 CS3773


Software requirements specification1
Software Requirements Specification

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 References

Can be put at the end of the document

UTSA CS3773


Software requirements specification2
Software Requirements Specification

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 CS3773


Software requirements specification3
Software Requirements Specification

Section 2 General description

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 CS3773


Software requirements specification4
Software Requirements Specification

Section 2 General description

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 CS3773


Software requirements specification5
Software Requirements Specification

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 CS3773


Software requirements specification6
Software Requirements Specification

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 CS3773


Software requirements specification7
Software Requirements Specification

Section 3 Specific requirements

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 CS3773


Software requirements specification8
Software Requirements Specification

Section 3 Specific requirements

3.3 Non-functional requirements

Reliability

Portability

Security

UTSA CS3773


Software requirements specification9
Software Requirements Specification

Section 4 Requirements table

  • Requirement number

  • Name

  • Description

  • Related requirements’ numbers and source

  • Related use cases’ numbers

UTSA CS3773


Reading assignments
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”

UTSA CS3773


ad