Requirements Engineering PPT 1

Lawrence Chung

Software

collection of programs to serve needs & perform tasks

Does SWE = Programmer

No, SWE is more than a programmer, they do a whole process

Agreement regarding requirements

legal contract between parties (e.g. business and specific problem) defining the requirements

Requirements

The basis for software design, support for verification, validation, and evolution

Requirements Engineering

A branch of SYSTEMS ENGINEERING concerned with REAL WORLD GOALS for SERVICES provided by, and CONTRAINTS on software systems. Concerned with RELATIONSHIPS of these factors to precise SPECIFICATIONS of system behavior and to their EVOLUTION

It’s about understand the problem and finding the solution

Types of Projects

Customer Driven Projects (large requirements, you need to fill lots of gaps)

Market Driven Projects (small requirements)

Software Lifecycle

Systems Engineering → Requirements Analysis → Architecture & Design → Implementation → Testing → QA & Metrics → Maintenance

Systems Engineering

Problems & Goals, 3 Wares (Hardware, Software, Peopleware) and how they interact to accomplish real world goals

Peopleware (3 categories of stakeholders)

OF THE stakeholders, BY THE devs, FOR THE users/customers

Error Propogation

Errors early in the lifecycle will stack up into bigger more costly problems later

Erroneous Spec

An incomplete or incorrect requirement specification. It is very costly later on in the lifecycle if not caught early

Forward Engineering

Top Down, building system from requirements down lifecycle

Reverse Engineering

Bottom Up, building system from the old implementation and building new set of requirements

1-10-100 Rule

$1 → In Requirements

$10 → In Design

$100 → After Release

Boehm 100X

Fixing problem later is 100 times more costly, mentioned different ratios 200:1 and 14:1

What’s the most serious defect in specification

incomplete requirements

3 Most Frequent Problems in Large Software Systems

1. Communication

2. Domain Knowledge

3. Changing/Conflicting Requirements

Factors that contribute to Project Sucess

1. User Involvement

2. Clear Business Objectives

3. Minimized Scope

4. Firm Basic Requirements

Factors that contribute to a Challenged Project

1. Lack of User Input

2. Incomplete Requirements & Spec

3. Changing Requirements & Spec

4. Unrealistic Expectations

5. Unclear Objectives

Factors that contribute to a Impaired Project

1. Incomplete Requirements

2. Lack of User Involvment

3. Unrealistic Expectations

4. Changing Requirements & Spec

5. Didn’t Need it any Longer

6. Technology Illiteracy

Why is Project Size Important?

As the size increase, the project’s success decreases because complexity and conflicting goals grow

Defining the Problem is ________

The Problem

Why is the cost of requirement errors more when repaired vs. when introduced?

It’s higher when repaired being that when repaired we have to roll back and repeat more steps in the software lifecycle. It’s simple error propagation. The cost multiplies at each stage

Modeling

Is a pattern/representation to show the inner workings of a concept

Systematic Decision Making

Is the outcome of mental processes which produce a final choice among many alternatives

What’s RE really about?

What does the customer really want?