cs 501 software engineering l.
Download
Skip this Video
Download Presentation
CS 501: Software Engineering

Loading in 2 Seconds...

play fullscreen
1 / 25

CS 501: Software Engineering - PowerPoint PPT Presentation


  • 101 Views
  • Uploaded on

CS 501: Software Engineering. Lecture 8 Requirements I . Administration. Project Presentations. Requirements. Requirements Analysis. System design. Design. Program design. Implementation. Coding. Unit & Integration Testing. System Testing. Acceptance Testing.

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 'CS 501: Software Engineering' - blanca


Download Now 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
cs 501 software engineering
CS 501: Software Engineering

Lecture 8

Requirements I

project presentations
Project Presentations

Requirements

Requirements Analysis

System design

Design

Program design

Implementation

Coding

Unit & Integration Testing

System Testing

Acceptance Testing

Operation & Maintenance

feedback in the waterfall model
Feedback in the Waterfall Model

Requirements Analysis

System design

Program design

Coding

Unit & Integration Testing

System Testing

Acceptance Testing

Operation & Maintenance

iterative refinement
Iterative Refinement

Concurrent

Activities

Initial

Version

Requirements

Outline

Description

Intermediate

Versions

Design

Implementation

Final

Version

from an old exam question
From an Old Exam Question

A computing system is likely to need some sort of database

(i) At what stage in the waterfall process, would the decision be made to use a relational database? Give the reasons for your answer.

(ii) At what stage in the waterfall process, would the decision be made to use an Oracle database? Give the reasons for your answer.

(iii) At what stage in the waterfall process would the database schema be specified? Give the reasons for your answer.

from an old exam question answer
From an Old Exam Question (Answer)

A requirement is a statement of need as expressed by a client.

The client's requirements are that the system collects certain data, saves it, and carries out specified processes, e.g., displaying it, performing calculations, etc.

The decision of how to store and manipulate the data (e.g., using the relational database model) is usually not a requirement of the client. It comes later, as part of the design.

However. During the feasibility study it is important to know about relational databases, such as Oracle, and to study their capabilities.

why are requirements important
Why are Requirements Important?

Causes of failed software projects (Standish Group study, 1994)

Incomplete requirements 13.1%

Lack of user involvement 12.4%

Lack of resources 10.6%

Unrealistic expectations 9.9%

Lack of executive support 9.3%

Changing requirements & specifications 8.8%

Lack of planning 8.1%

System no longer needed 7.5%

The commonest mistake is to build the wrong system!

evolution of requirements
Evolution of Requirements

• If the requirements definition is wrong, the system will be

a failure.

• With complex systems, understanding of requirements

always continues to improve.

Therefore...

• The requirements definition must evolve.

• Its documentation must be kept current (but clearly

identify versions).

goals during the requirements phase
Goals During the Requirements Phase

• Understand the requirements in detail (analysis)

• Describe the requirements in a manner that is clear to the client

• Ensure that the client understands the description of the requirements and their implications

• Describe the requirements in a manner that is clear to the people who will design and implement the system

the requirements process

Requirements

Analysis

Requirements

Specification

Requirements

Definition

The Requirements Process

Feasibility

Study

Feasibility

Report

System

Models

Definition of

Requirements

Specification of

Requirements

Requirements

Document

functional requirements
Functional Requirements
  • Requirements about the functions
  • that the system must perform
  • Functionality
  • Data
  • Interfaces
  • Users and human factors
example of functional requirements
Example of Functional Requirements

Library of Congress Repository

• Support for complex digital objects. (How many? What size?)

• Access management. (What users? What objects? Policies?)

• Identification. (Which identification system?)

• Information hiding. (Where are the interfaces?)

• Open protocols and formats. (How are these chosen?)

• Integration with existing systems (What legacy systems must be accommodated?).

slide14

DRAFT OVERVIEW OF ITS SUPPORT

FOR NDLP PRODUCTION AND DELIVERY OF AMERICAN MEMORY

NDLP collections

already released

Coolidge collection

(for repository test)

NDLP collections

in conversion

Future

NDLP collections

Other applications

and materials

NDLP Workflow

Tracking Support

Current Storage Structure

(in Unix files, by aggregate)

Object Administration System

ILS

Repository

Index Generation

(including pre-processing)

American Memory User Interface

(retrieval, navigation, & display)

AM user interface plus

access management

for objects/collections

Other User Interfaces

(e.g. RLG, OCLC, DLF partners)

ILS OPAC Interface

Supporting infrastructure

Handle assignment

& registration

Handle resolution

Handle-server

NOW

FUTURE

non functional requirements
Non-Functional Requirements
  • Requirements about the context in
  • which the system is built
  • Documentation and training
  • Resources
  • Security
  • Physical environment
  • Quality assurance
examples of functional and non functional requirements
Examples of Functional and Non-Functional Requirements

Privacy (Mercury digital library)

Functional requirement:

Usage data for management of system

Non-functional requirement:

Usage data must not identify individuals

Minimizing records (NeXT)

Functional requirement:

Retain all required records

Non-functional requirement:

Discard all other records

non functional requirements17
Non-Functional Requirements

Product requirements

performance, reliability, portability, etc...

Organizational requirements

delivery, training, standards, etc...

External requirements

legal, interoperability, etc...

Marketing and public relations

Example: In the NSDL, the NSF wanted a system that could be demonstrated by the end of 2002

example of non functional requirements
Example of Non-Functional Requirements
  • Example: Library of Congress Repository
  • Hardware and software systems (IBM/Unix)
  • Database systems (Oracle)
  • Programming languages (C and C++)
  • Regulations covering government contracting
  • Importance of developing a system that will be respected by other major libraries
unspoken requirements
Unspoken Requirements
  • Example:
  • Resistance to change
  • Departmental friction
  • Management strengths and weaknesses
requirements analysis and definition
Requirements Analysis and Definition

High-level abstract description of requirements:

• Specifies external system behavior

• Comprehensible by customer, management and users

Should reflect accurately what the customer wants:

• Services that the system will provide

• Constraints under which it will operate

Described in a Requirements Document that can be understood by the client.

requirements analysis
Requirements Analysis

1. Identify the stakeholders:

• Who is affected by this system?

Client

Senior management

Production staff

Computing staff

Customers

etc., etc., etc.,

Example: Andrew project (Carnegie Mellon and IBM?)

• Who can disrupt this project?

requirements analysis22
Requirements Analysis

2. Understand the requirements in depth:

• Domain understanding

Examples: Philips light bulbs

• Understanding of the real requirements of all stakeholders

interviews with clients
Interviews with Clients

Client interviews are the heart of requirements analysis and definition. Allow plenty of time.

Clients may have only a vague concept of requirements.

• Prepare before you meet with them

• Keep full notes

• If you don't understand, delve further

• Repeat what you hear

• Small group meetings are often most effective

Clients often confuse the current system with the underlying requirement.

viewpoint analysis
Viewpoint Analysis

Example: University Admissions System

• Applicants

• University administration

Admissions office

Financial aid office

Special offices (e.g., athletics, development)

• Computing staff

Operations

Software development and maintenance

• Academic departments

requirements analysis25
Requirements Analysis

3. Organize the requirements:

• Classification into coherent clusters

(e.g., legal requirements)

• Recognize and resolve conflicts

(e.g., functionality v. cost v. timeliness)

Example: Dartmouth general ledger system

ad