7/30/2019 3 Req Determination
1/36
7/30/2019 3 Req Determination
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:
7/30/2019 3 Req Determination
3/36
3
An activity used to determine what is in and what is out!
Problem Domain Details
Requirements Determination Activity
Problem DomainRequired Details
7/30/2019 3 Req Determination
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:
7/30/2019 3 Req Determination
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.
7/30/2019 3 Req Determination
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/30/2019 3 Req Determination
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.
7/30/2019 3 Req Determination
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:
7/30/2019 3 Req Determination
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.
7/30/2019 3 Req Determination
10/36
User-Driven
User-Reviewed
User-Independent
There are three
major types of requirements:
7/30/2019 3 Req Determination
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.
7/30/2019 3 Req Determination
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.
7/30/2019 3 Req Determination
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.
7/30/2019 3 Req Determination
14/36
Three Perspectives:
7/30/2019 3 Req Determination
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
7/30/2019 3 Req Determination
16/36
Perspective:Individual
7/30/2019 3 Req Determination
17/36
Perspective:Collective (group)
7/30/2019 3 Req Determination
18/36
Three CommonThreads in all Methods:
7/30/2019 3 Req Determination
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
7/30/2019 3 Req Determination
20/36
Requirements usually have one ormore of the following 8 problems:
7/30/2019 3 Req Determination
21/36
7/30/2019 3 Req Determination
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.
7/30/2019 3 Req Determination
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.
7/30/2019 3 Req Determination
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.
7/30/2019 3 Req Determination
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.
7/30/2019 3 Req Determination
26/36
7/30/2019 3 Req Determination
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.
7/30/2019 3 Req Determination
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.
7/30/2019 3 Req Determination
29/36
Four sub-activities
Kozars Requirements Model
Enterprise Objects
How to get started?????
7/30/2019 3 Req Determination
30/36
Framework #1:Requirements Determination Sub-Activities
7/30/2019 3 Req Determination
31/36
7/30/2019 3 Req Determination
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
Kozars Requirements Model
7/30/2019 3 Req Determination
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.....
Kozars Requirements Model
Business Objectivescreate one or moreBusiness Tactics
Business Tacticscreate zero or more
Information SystemsObjectives
Information SystemsObjectives create
one or moreInformation Systems
Tactics
7/30/2019 3 Req Determination
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
7/30/2019 3 Req Determination
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
7/30/2019 3 Req Determination
36/36
Enterprise Objects
InformationSystem
Business Objects
Technology Objects
Application Objects