System Requirements Determination

 Two forms:
Characteristics for Successful Requirements Determination  Open-ended: conversational, questions with no specific
answers in mind
 Impertinence  Closed-ended: structured, questions with limited range of
possible answers
 Impartiality
Guidelines for Effective Interviewing
 Relaxing constraints
 Plan the interview.
 Attention to details  Prepare interviewee: appointment, priming questions.
Prepare agenda, checklist, questions.
 Reframing


 Listen carefully and take notes (tape record if permitted).

Deliverables of Requirements Determination
 Review notes within 48 hours.
 From interviews and observations
 Be neutral.
 Interview transcripts, observation notes, meeting minutes
 From existing written documents  Seek diverse views.
 Mission and strategy statements, business forms, procedure
manuals, job descriptions, training manuals, system documentation, Disadvantages of Individual Interviews
flowcharts  Interview one person at a time
 From computerized sources
 Advantages
 JAD session results, CASE repositories, system prototype
displays and reports  Easier to schedule than group interviews
 Disadvantages
Traditional Requirements Determination Methods  Contradictions and inconsistencies between interviewees
Follow-up discussions are time consuming
 Interviewing individuals


Group Interviews
 Interviewing groups
 Interview several key people together
 Observing workers  Advantages
 More effective use of time
 Studying business documents 

Can hear agreements and disagreements at once
Opportunity for synergies
What is Interviewing?  Disadvantages
More difficult to schedule than individual interviews
 Dialogue with user or manager to obtain their requirements


Nominal Group Technique (NGT)

 Report
 A facilitated process that supports idea generation by groups.

 Enables the analyst to work backwards from the report to the
 Process data that generated it
 Members come together as a group, but initially work  Description of current information system
separately.
 Each person writes ideas. Potential Problems with Procedure Documents
Facilitator reads ideas out loud, and they are written on

blackboard.
 May involve duplication of effort


Group discusses the ideas.
Ideas are prioritized, combined, selected, reduced.
 May have missing procedures

 May be out of date

Other Approaches
 May contradict information obtained through interviews
 What is Direct Observation?
 Watching users do their jobs Formal
 Can provide more accurate information than self-reporting  The official way a system works as described in organization’s
(like questionnaires and interviews) documentation
Procedure documents describe formal system
 What is Document Analysis?

Informal
 Review of existing business documents  The way a system actually works in practice
 Can give a historical and “formal” view of system  Interviews and observation reveal informal system
requirements

Analyzing Procedures and Other Documents Contemporary Methods for Determining Requirements
 Types of information to be discovered:  Joint Application Design (JAD)
 Problems with existing system  Brings together key users, managers, and systems analysts
 Opportunity to meet new need  Purpose: collect system requirements simultaneously from
 Organizational direction key people
 Names of key individuals  Conducted off-site
 Values of organization
 Special information processing circumstances  Group Support Systems
 Reasons for current system design  Facilitate sharing of ideas and voicing of opinions about
 Rules for processing data system requirements
 Four types of useful documents  CASE tools
 Written work procedures  Used to analyze existing systems
 Describes how a job is performed  Help discover requirements to meet changing business
 Includes data and information used and created in the process conditions
of performing the job or task
 Business form
 System prototypes
 Iterative development process
 Explicitly indicate data flow in or out of a system
  Rudimentary working version of system is built  Members type their answers into the computer
 Refine understanding of system requirements in concrete  All members of the group see what other members have been
terms typing

Joint Application Design (JAD) Prototyping

 Intensive group-oriented requirements determination technique  Quickly converts requirements to working version of system

 Team members meet in isolation for an extended period of time
 Highly focused
 Resource intensive
 Started by IBM in 1970s
JAD Participants
 Session Leader: facilitates group process
 Users: active, speaking participants
 Managers: active, speaking participants
 Sponsor: high-level champion, limited participation
 Systems Analysts: should mostly listen
 Once the user sees requirements converted to system, will ask for
modifications or will generate additional requests
 Most useful when:


User requests are not clear
Few users are involved in the system
 Designs are complex and require concrete form
 History of communication problems between analysts and
users
 Tools are readily available to build prototype
 Drawbacks
 Tendency to avoid formal documentation
 Difficult to adapt to more general user audience
 Sharing data with other systems is often not considered
 Systems Development Life Cycle (SDLC) checks are often
bypassed

 Scribe: record session activities Business Process Reengineering (BPR)

 IS Staff: should mostly listen  Search for and implementation of radical change in business
 End Result processes to achieve breakthrough improvements in products and services
Documentation detailing existing system

 Features of proposed system
 Goals
 Reorganize complete flow of data in major sections of an
 CASE Tools During JAD organization
 Upper CASE tools are used  Eliminate unnecessary steps
 Enables analysts to enter system models directly into CASE  Combine steps
during the JAD session  Become more responsive to future change
Screen designs and prototyping can be done during JAD and

shown to users
 Identification of processes to reengineer
 Key business processes
 Supporting JAD with GSS  Set of activities designed to produce specific output for a
 Group support systems (GSS) can be used to enable more particular customer or market
participation by group members in JAD  Focused on customers and outcome
  Same techniques are used as were used for requirements
determination
 Identify specific activities that can be improved through BPR
 Disruptive technologies
 Technologies that enable the breaking of long-held business
rules that inhibit organizations from making radical business changes
Agile Methodologies for Requirements Determination
 Continual user involvement
 Replace traditional SDLC waterfall with iterative analyze –
design – code – test cycle
 Agile usage-centered design
 Focuses on user goals, roles, and tasks
 The Planning Game
 Based on eXtreme programming
 Exploration, steering, commitment
Agile Usage-Centered Design Steps
 Gather group of programmers, analysts, users, testers, facilitator
 Document complaints of current system
 Determine important user roles
 Determine, prioritize, and describe tasks for each user role
 Group similar tasks into interaction contexts
 Associate each interaction context with a user interface for the
system, and prototype the interaction context
 Step through and modify the prototype
Structuring System Process Requirements
Process Modeling
 Graphically represent the processes that capture, manipulate, store,
and distribute data between a system and its environment and among system
components
 Utilize information gathered during requirements determination
 Processes and data structures are modeled
Deliverables and Outcomes
 Context data flow diagram (DFD)
 Scope of system
 DFDs of current physical and logical system
 Enables analysts to understand current system
 DFDs of new logical system
 Technology independent
 Show data flows, structure, and functional requirements of
new system
 Thorough description of each DFD component
Data Flow Diagram (DFD)
 A picture of the movement of data between external entities and the
processes and data stores within a system
 Difference from system flowcharts:
 DFDs depict logical data flow independent of technology
 Flowcharts depict details of physical systems
DFD Symbols
 Process: work or actions performed on data (inside the system)
 Data store: data at rest (inside the system)
 Source/sink: external entity that is origin or destination of data
(outside the system)
 Data flow: arrows depicting movement of data
 Data flow from a process to a data store means update (insert, delete
or change).
 Data flow from a data store to a process means retrieve or use.
 Data flow labels should be noun phrases.
Functional Decomposition  Current system is reduced to data and processes that
transform them.
 An iterative process of breaking a system description down into finer
and finer detail  New Logical
 Includes additional functions
 High-level processes described in terms of lower-level sub-processes  Obsolete functions are removed
Inefficient data flows are reorganized
 DFD charts created for each level of detail


DFD Levels  New Physical

 Context DFD  Represents the physical implementation of the new system
 Overview of the organizational system
 Level-0 DFD Guidelines for Drawing DFDs
 Representation of system’s major processes at high level of
abstraction  Completeness

 Level-1 DFD  Consistency

 Results from decomposition of Level 0 diagram
 Timing
 Level-n DFD
 Results from decomposition of Level n-1 diagram  Iterative Development

DFD Balancing  Primitive DFDs

 The conservation of inputs and outputs to a data flow process when  Rules for stopping decomposition
that process is decomposed to a lower level
 Rules for stopping decomposition (continued)
 Balanced means:
 Number of inputs to lower level DFD equals number of Using DFDs as Analysis Tools
inputs to associated process of higher-level DFD
 Number of outputs to lower level DFD equals number of  Gap Analysis
outputs to associated process of higher-level DFD  The process of discovering discrepancies between two or
more sets of data flow diagrams or discrepancies within a single DFD
Four Different Types of DFD
 Inefficiencies in a system can often be identified through DFDs.
 Current Physical
 Process labels identify technology (people or systems) used UML Use Case Diagram Symbols
to process the data.
 Data flows and data stores identify actual name of the What is an Actor?
physical media.
 Actor is an external entity that interacts with the system.
 Current Logical
 Most actors represent user roles, but actors can also be external
 Physical aspects of system are removed as much as possible.
systems.
 An actor is a role, not a specific user; one user may play many roles,
Structuring System Logical Requirements
and an actor may represent many users.
Logic Modeling
What is a Boundary?
 A boundary is the dividing line between the system and its
 Data flow diagrams do not show the logic inside the processes.
environment.  Logic modeling involves representing internal structure and
functionality of processes depicted on a DFD.
 Use cases are within the boundary.

 Actors are outside of the boundary.

 Logic modeling can also be used to show when processes on a DFD
occur.
What is a Connection? Logic Modeling Deliverables and Outcomes
 A connection is an association between an actor and a use case.  Structured English
 Depicts a usage relationship  Decision Tables
 Connection does not indicate data flow  Decision Trees
What is an <<extend>> Relationship?  State-transition diagrams
 A connection between two use cases  Sequence diagrams
 Extends a use case by adding new behavior or actions  Activity diagrams
 Specialized use case extends the general use case
Modeling Logic with Structured English
 Modified form of English used to specify the logic of information
processes
What is an <<include>> Relationship?
 Uses a subset of English
 A connection between two use cases  Action verbs
Noun phrases
 Indicates a use case that is used (invoked) by another use case

 No adjectives or adverbs
 Links to general purpose functions, used by many other use cases  No specific standards
Written Use Cases Modeling Logic with Decision Tables
 Document containing detailed specifications for a use case  A matrix representation of the logic of a decision
 Contents can be written as simple text or in a specified format  Specifies the possible conditions and the resulting actions
 Best used for complicated decision logic  All possible actions are listed on the far right

3 Parts of a Decision Table

 Condition stubs
 Lists condition relevant to decision
 Action stubs
 Actions that result from a given set of conditions
 Rules
 Specify which actions are to be followed for a given set of
conditions
 Indifferent Condition
 Condition whose value does not affect which action is taken
for two or more rules

Procedure for Creating Decision Tables

 Name the condition and values each condition can assume
 Name all possible actions that can occur
 List all rules
 Define the actions for each rule
 Simplify the table

Modeling Logic with Decision Trees

 A graphical representation of a decision situation
 Decision situation points are connected together by arcs and terminate
in ovals
 Main components
 Decision points represented by nodes
 Actions represented by ovals
 Particular choices from a decision point represented by arcs
 Read from left to right

 Each node corresponds to a numbered choice on a legend