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

Requirements Capture-Learn Object Oriented Programming-Lecture Slides, Slides of Object Oriented Programming

This lecture was delivered by Agstya Rao at Bidhan Chandra Krishi Viswa Vidyalaya for Object Oriented Programming course. It inlcudes: Requirements, Capturing, Document, Methods, Utilizing, Cases, Condition, Capability, System, Functional, Usability

Typology: Slides

2011/2012

Uploaded on 07/17/2012

banani
banani 🇮🇳

4.3

(3)

91 documents

1 / 8

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
Dr. Jamil Ahmed 1
Requirements Capturing
Lecture 13
Dr. Jamil Ahmed 2
Overview
nRequirements defined
nCurrent vs. New Requirements
nWhy capture and document requirements?
nMethods of Requirement Capture
nUse cases
nUtilizing use cases for documenting
Dr. Jamil Ahmed 3
“Requirement” Defined
lA condition or capability needed by a user to solve
a problem or achieve an objective.
lA condition or capability that must be met or
possessed by a system or system component to
satisfy a contract, standard, specification, or other
formally imposed documents.
docsity.com
pf3
pf4
pf5
pf8

Partial preview of the text

Download Requirements Capture-Learn Object Oriented Programming-Lecture Slides and more Slides Object Oriented Programming in PDF only on Docsity!

Dr. Jamil Ahmed 1

Requirements Capturing

Lecture 13

Dr. Jamil Ahmed 2

Overview

n Requirements defined

n Current vs. New Requirements

n Why capture and document requirements?

n Methods of Requirement Capture

n Use cases

n Utilizing use cases for documenting

Dr. Jamil Ahmed 3

“Requirement” Defined

l A condition or capability needed by a user to solve

a problem or achieve an objective.

l A condition or capability that must be met or

possessed by a system or system component to

satisfy a contract, standard, specification, or other

formally imposed documents.

Dr. Jamil Ahmed 4

Types of Requirements

n Current System Requirements

n New Requirements

Dr. Jamil Ahmed 5

Classification of Requirements

n Functional requirements

n Non-functional requirements

n Usability requirements

n Inverse requirements

Dr. Jamil Ahmed 6

Functional Requirements

n These requirements specify the system

n Include:

n Processing to be carried out by the system

n Data input

n Data output

n Data retention, persistence, storage

Dr. Jamil Ahmed 10

Requirements Capture

n Requirements capture

attempts to obtain a

complete, consistent and

unambiguous specification of

requirements shared by

different stakeholder groups.

n The main objective of this

activity is to collect,

formalize, analyze and

validate customer

requirements

n A documented collection of

requirements, the

requirements specification, is

a statement of consensus

between the suppliers and

customers of a software

system.

n Requirements constitutes the

basis for the subsequent

software design, and

provides a reference point

for any future validation of

the constructed software.

Dr. Jamil Ahmed 11

Steps in Requirements

Capture

n Elaboration of needs and objectives sets the objectives for

the software system.

n Requirements acquisition aims at complete characterization

of the problem by eliciting all the necessary concepts from users

n Requirements modeling is necessary to organize and record

all the collected information into a system specification.

n Generation and evaluation of alternatives is used to

generate alternative software specifications.

n Requirements validation aims at analyzing specifications for

their compliance with the original client requirements, the

existence of inconsistencies, ambiguities, or missing

Dr. Jamil Ahmed 12

Methods of Collecting

Requirements

n Traditional methods

n Studying documents

n Interviews

n Observation

n Document Sampling

n Questionnaires

n Modern Methods

n Joint application

development (JAD);

n Prototyping;

n Simulation and

scenarios.

Dr. Jamil Ahmed 13

Documents

n Examining system and

organizational documents

provides an effective way to

discover more details about

the current system.

n Useful documents include:

n mission statement

n business plans

n organizational charts

n policy manuals

n job descriptions

n internal and external mail

n reports and manuals

n In documents you can find:

n problems

n opportunities

n directions

n people

n priorities

n irregularities

n data

n rules

Dr. Jamil Ahmed 14

Interviews

n During interviews you will

gather facts, opinions and

speculations, and observe

body language and

emotions.

n Guidelines for effective

interviewing:

n Plan the interview

n Listen carefully

n Take notes (tape if

n permitted)

n Review notes

n Be neutral

n Seek diverse views.

n An interview plan may

include:

n Names of interviewer and

interviewee

n Location / medium, time

n Objectives

n Reminders

n Agenda (with anticipated

n time estimates)

n General information

n Unresolved issues

n Questions asked with

n answers and observations

n Use open and close

questions

Dr. Jamil Ahmed 15

Observation

n People cannot always be trusted to reliably interpret

and report their own actions.

n Observations supplement and corroborate what

people tell you by watching what they do.

n The main aim of observation is to obtain more first

hand measures of employee interaction with

information system.

n Note, however, that observation can cause people to

change their normal operating behavior.

n Since observation cannot be usually continuous, you

a snapshot of real behavior.

Dr. Jamil Ahmed 19

Typical SRS Outline

3.1 External Interface Req. 3.2.1 User Interfaces 3.2.2 Hardware Interfaces 3.2.3 Software Interfaces 3.3 Performance Req. 3.4 Design Constraints 3.4.1 Standards Compliance 3.4.2 Hardware Limitations 3.5 Attributes 3.6 Other Requirements 3.6.1 Database 3.6.2 Operations 3.6.3 Site Adaptation

Appendices

A. Context diagram and operating

B. Data/control flow diagrams C. Data dictionary

3.5.1 Security 3.5.2 Safety 3.5.3 Correctness 3.5.4 Availability 3.5.5 Reliability 3.5.6 Efficiency 3.5.7 Integrity 3.5.8 Usability 3.5.9 Maintainability 3.5.10 Testability 3.5.11 Flexibility 3.5.12 Portability 3.5.13 Reusability 3.5.14 Interoperability 3.5.15 Other Factors

Software AttributesSoftware Attributes

Dr. Jamil Ahmed 20

Use Cases

n It is becoming increasingly

common to illustrate

functional requirements with

use cases.

n Use cases show many

different ways of using the

system.

n Each use case identifies an

abstract system function.

n Each use case also identifies

people and organizations, or

actors , outside the system

that are affected by that

system function.

n An actor may participate in

many use cases.

n Use cases define a system

boundary.

Dr. Jamil Ahmed 21

Use Case Description

n Overview

n Preconditions

n Postconditions

n Initiation

n Navigation

n Page One

n Page Two…

n Page Details

n Initial State

n Details of Controls

n Exceptions

n Notes

Dr. Jamil Ahmed 22

Summary

n What are requirements?

n Why should requirements be documented?

n What type of information is commonly documented in

requirements documents?

n What are typical activities in requirements capture?

n What are the requirements capture methods?

n What are the necessary qualities of requirements

n What’s the role of use cases in requirements