3 Req Determination

7/30/2019 3 Req Determination

1/36


2/36

Name & Address Book

CD Collection

Course Registration

Reservations

Student Grades

Payroll

ATM machine & Banking in General

Check-Out Counters at Retail Stores

Order Fulfillment - Mail or Web Ordering Manufacturing

Securities Portfolio Management

Space Shuttle Flight

Election Results

Video Games (Arcade and Home)

Business problem

s come in

all sizes and shapes!

Examples:


3/36

3

An activity used to determine what is in and what is out!

Problem Domain Details

Requirements Determination Activity

Problem DomainRequired Details


4/36

are criteria that are

necessary, needed, or demanded.

are implicit or explicit

criteria that must, should, or might be met. equal the wants and needs

of the user(s).

Three (3) alternative ways to think aboutRequirements:


5/36

Requirements are not supposed to dictate any detailsregarding the implementation of a solution. We commonly define differing levels of necessity for our

requirements, such as absolutely must be satisfied,nice to have, and optional.

Some requirements may apply to an entire system,while others apply only to part of the system.

Compromise is often necessary for conflictingrequirements from different user(s).

Some requirements are static, while others are dynamicand evolve or emerge over time.

Requirements are not always easy to explain(communicate), understand, or document.


6/36

One very common way to document requirements is a

textual document containing a list of numbered or

bulleted items, i.e., the requirements.

Each requirement is (ideally) stated in the form of a

single sentence.

Each sentence contains a word such as must, shall,

should, will, might, or can.

The document contains a way of differentiating those

requirements which are essential/demanded from thoserequirements which are optional/suggested.


7/36

Text is not the optimum form for all requirements.

For GUI, specifying colors, window layouts, and the placement of

icons is more easily and directly done using graphical

techniques.

For systems using audio, animation, video capture, etc., it is

difficult to be precise if we are limited to textual descriptions.

Both static and dynamic models may be necessary to accurately

and correctly document requirements.


8/36

Product Requirements

define the criteria that must, should, or, mightbe met by the delivered product.

Project Requirements stipulates resources for those conducting the

project.

stipulates how different aspects of the projectwill be carried out.

Two very different

sets of requirements:


9/36

Both product and project requirements may have

associated priorities and constraints.

A priority is a level of importance assigned to an item

helps define which items take precedence over other

items.

A constraint is a limit or a restriction placed on an item

or situation

helps define the scope (boundaries) of an item or

situation.


10/36

User-Driven

User-Reviewed

User-Independent

There are three

major types of requirements:


11/36

Defined and specified entirely by the user.

The systems analyst has little, or no, input tothe definition and specification of the system

requirements.


12/36

Specified by the user and the systems analyst

working together.

It is not the analysts job to be an expert in the

users application domain. It is, however, required that systems analysts

possess the skills, methods, techniques, and

tools with which they effectively define, specify,

and verify requirements through interactionswith the user.


13/36

Defined and specified without a particular

user being present.

The most common example of user-independent requirements are those

requirements which are defined by

software product vendors when they

choose to develop a new software product.


14/36

Three Perspectives:


15/36

Reviewing old reports, forms, and files

Conducting research to find out what other

companies have done - books, magazines,

newspapers, trade & scholarly journals, vendor

literature, colleagues, web... Conducting site visits

Perspective:Global


16/36

Perspective:Individual


17/36

Perspective:Collective (group)


18/36

Three CommonThreads in all Methods:


19/36

REQUIREMENTS AMBIGUITY

GOAL

whattheuserwants/needs

whattheuserdoes notwant/

need

START WITH

want/need,but theydo notask for

do not

want/need,but ask for

EXPLOREand

ITERATE


20/36

Requirements usually have one ormore of the following 8 problems:


21/36


22/36

Contradictions may be the result of: incomplete information

imprecise specification methods

a misunderstanding

a lack of consistency check on the requirements.

If the user alone cannot resolve the

contradictions, the analyst will be required

to propose a resolution to each problem.


23/36

Ambiguities are often the result of: incompletely defined ideas

use of ambiguous words (e.g., big, small)

lack of precision in the specification method

a conscious decision to leave resolution of ideasto the analysts performing analysis.

Resolution of ambiguities with user input isimportant otherwise the resolution is left in

the hands of the systems analyst.


24/36

Duplications may be the outright replication of information in the

same format in a different place the replication of the same information in

several different places and formats.

Sometimes duplications are not obvious the use of several different terms to describe the

same item.

The systems analyst must be careful whenidentifying and removing duplications.


25/36

It is not uncommon for systems analysts touncover information which they suspect isincorrect.

Inaccuracies must be brought to the usersattention and resolved.

Often, it is not until the user is confrontedwith a precisely-described, proposedrequirements document that many of the

inaccuracies in the original requirementscome to light.


26/36


27/36

One of the greatest temptations in systemsanalysis is to do the next persons job. i.e., to both define a problem and to propose a

(detailed) solution.

One of the most difficult activities duringanalysis is the separation of realrequirements from arbitrary (and

unnecessary) design decisions made bythose supplying the requirements.


28/36

Systems analysts are often reluctant tothrow away any information.

Users sometimes feel it is better to supply

too much information rather than too little(usually just the opposite). Without some clear cut mechanisms to

identify and remove irrelevant information, itwill be difficult to develop accurate, cost-effective, and pragmatic solutions to ausers problems.


29/36

Four sub-activities

Kozars Requirements Model

Enterprise Objects

How to get started?????


30/36

Framework #1:Requirements Determination Sub-Activities


31/36


32/36

STIMULI

BUSINESS OBJECTIVES

BUSINESS TACTICS

INFORMATION SYSTEMS OBJECTIVES

INFORMATION SYSTEMS TACTICS

Creates one or more

Creates one or more

Creates zero or more

Creates one or more



33/36

Business Objectives1. ......2. ......3. ......4. ......

etc....

Business Tactics1.1 ......1.2 ......1.3 ......2.1 ......

3.1 ......3.2 ......4.1 ......4.2 ......4.3 ......4.4 ......etc....

Info. Sys. Objectives1.1.11.1.21.1.31.2.1

1.2.22.1.12.1.2etc...

Info. Sys. Tactics1.1.1.11.1.1.21.1.1.31.1.1.4

1.1.2.11.1.2.21.1.3.1etc.....


Business Objectivescreate one or moreBusiness Tactics

Business Tacticscreate zero or more

Information SystemsObjectives

Information SystemsObjectives create

one or moreInformation Systems

Tactics


34/36

Framework #3: Enterprise Objects

A strategy that maps information systems business

objects with established business functionalities.

PREMISE: Information systems support integrated

business activities; therefore, they should mimic the real

world business activities as closely as possible.

Provides verification and validation (V & V) traceability


35/36

Objects are not all created equal:

Different object types address different issues

Process and management issues differ

Buy vs. Make decision driven by different motivations

Three types of objects:

Business- business concepts / components, sharable across a

company or industries, independent of applications (ex: customer,

employee, product, vehicle, transcript, course...)

Technology- software and infrastructure building blocks,

frameworks for software development (ex: windows, forms,

controls)

Application- user interfaces to business objects as solutions to

specific business problems (ex: Order Entry, Ticketing, Acct setup)

Enterprise Objects


36/36

Enterprise Objects

InformationSystem

Business Objects

Technology Objects

Application Objects

Documents

3 Req Determination