Docsity
Docsity

Prepare for your exams
Prepare for your exams

Study with the several resources on Docsity


Earn points to download
Earn points to download

Earn points by helping other students or get them with a premium plan


Guidelines and tips
Guidelines and tips

Software Engineering: Understanding the Requirements Engineering and Analysis Gap - Prof. , Study notes of Computer Science

A lecture note from a university course on object-oriented analysis and design (csci 6448) taught by kenneth m. Anderson during the spring semester of 2001. The lecture focuses on software engineering, requirements engineering, requirements analysis, and the requirements/design gap. Software engineering is defined as the application of scientific principles to create, develop, operate, and maintain cost-effective, reliable, and high-quality software solutions. Requirements engineering is the systematic process of discovering and documenting requirements through an iterative cooperative process. Requirements analysis is the process of understanding the requirements and checking their completeness and consistency. The lecture also discusses the requirements/design gap, which occurs when not all phenomena are shared between the application domain and the machine domain.

Typology: Study notes

Pre 2010

Uploaded on 02/13/2009

koofers-user-f3j
koofers-user-f3j 🇺🇸

10 documents

Partial preview of the text

Download Software Engineering: Understanding the Requirements Engineering and Analysis Gap - Prof. and more Study notes Computer Science in PDF only on Docsity!

Lecture 2: The

Requirements/Design Gap

Kenneth M. Anderson

Object-Oriented Analysis and DesignCSCI 6448 - Spring Semester, 2001

January 18, 2000

' Kenn

eth M. Anderson, 2001

Goals for this Lecture

  • Review definition of software engineering• Discuss requirements engineering• Discuss requirements analysis• Discuss requirements/design gap

January 18, 2000

' Kenn

eth M. Anderson, 2001

3

What is “Software Engineering”

  • Software
    • Computer programs and their related artifacts
      • Engineering
        • The application of scientific principles in the

context of practical constraints

January 18, 2000

' Kenn

eth M. Anderson, 2001

A Definition (Daniel M. Berry)

•^

Software engineering is that form of engineeringthat applies:– a systematic, disciplined, quantifiable approach,– the principles of computer science, design,

engineering, management, mathematics,psychology, sociology, and other disciplines,

•^

to creating, developing, operating, andmaintaining cost-effective, reliably correct, high-quality solutions to software problems.

January 18, 2000

' Kenn

eth M. Anderson, 2001

5

Engineers Build Machines

•^

Software is intangible– Descriptions of a desired machine, written according to

specific languages and notations

•^

Computer is tangible– General-purpose description executor– Behaves as if it were the desired machine

-^

Software engineers “build” descriptions– Organizing, structuring, and making complex

assemblages of descriptions

  • Raw materials: languages and notations

January 18, 2000

' Kenn

eth M. Anderson, 2001

Basic Software Engineering Activities

•^

Create– Modeling

-^

Record– Specification

-^

Analyze– Verification & Validation

-^

Configure– Selection, Translation, & Deployment

January 18, 2000

' Kenn

eth M. Anderson, 2001

7

IEEE definition of requirement

•^

A condition or capacity needed by a user to solvea problem or achieve an objective

-^

A condition or capability that must be met orpossessed by a system or system component tosatisfy a contract, standard, specification or otherformally imposed documents

-^

A documented representation of a condition orcapability as in 1 or 2

January 18, 2000

' Kenn

eth M. Anderson, 2001

Requirements Engineering

  • “The systematic process of developing

requirements through an iterativecooperative process of analyzing theproblem, documenting the resultingobservations in a variety of representationformats, and checking the accuracy of theunderstanding gained.”– K. Pohl, 1993

January 18, 2000

' Kenn

eth M. Anderson, 2001

13

Application versus Machine Phenomena•^

Not all phenomena are shared

-^

Creates requirements/design gap

-^

Example: Elevator Controller– Car movement while between sensors– Correspondence of person pushing button to person

exiting Application Domain

Machine

A

M

A

M

January 18, 2000

' Kenn

eth M. Anderson, 2001

14

Does System Satisfy

Requirements?

If computer behaves as P, then S satisfied

  • C,P

a

S, where C are the properties of the computer

If S satisfied, then R must be satisfied

  • D,S

a

R, where D are the properties of the application

domain

R(equirements)

A P(rogram)

M

S(pec.)

A

∩∩∩∩

M

Application Domain

Machine

A

M

A

M

January 18, 2000

' Kenn

eth M. Anderson, 2001

15

Application Domain

Machine

A

M

A

M

Understanding Domain is Critical•^

Example: Automated Thrust Reverser– Requirement

-^

reverse_enabled

IFF

moving_on_runway

  • Domain Properties Assumed by Developers -^

wheel_pulses_on

IFF

wheels_turning

-^

wheels_turning

IFF

moving_on_runway

wheel_pulses_on

moving_on_runway

wheels_turning

reverse_enabled

January 18, 2000

' Kenn

eth M. Anderson, 2001

16

Domain Misunderstandings

Errors

  • Example: Automated Thrust Reverser
    • Derived Interface Specification -^

reverse_enabled

IFF

wheel_pulses_on

  • Domain Properties Assumed by Developers

wheel_pulses_on

IFF

wheels_turning

wheels_turning

IFF

moving_on_runway

  • Aquaplaning Wheels -^

moving_on_runway

is TRUE

-^

wheels_turning

is FALSE