Transcript Document
ITEC 3010 “Systems Analysis and Design, I”
LECTURE 4:
Investigating System Requirements
[
Prof. Peter Khaiter
] 1
Lecture Outline
The Analysis Phase System Requirements Models and Modeling Stakeholders Information Gathering Prototypes Joint Application Design Sessions Structured Walkthrough
2
The Analysis Phase in More Detail
Gather information ( from people who will be using the system ) • by interviewing them • by observing their work • by reviewing documents and policy statements (e.g. at a bank) Define system requirements Functional and nonfunctional Prioritize requirements Prototype for feasibility and discovery Generate and evaluate alternatives Review recommendations with management 3
The Activities of the Analysis Phase
4
The Analysis Phase
Gather Information
System analyst needs to become an expert in the business area the system will support or should even actually do some or part of the task to get a feel for what is done (e.g., in order to automate order-entry, may need to know how orders are processed) Gathered information involves: • Understanding the existing system • Identifying all current and future users, locations, might be used 5
The Analysis Phase
Prioritize Requirements
• Establish which functional and technical requirements are most critical • • Why? Since resources are always limited and you want to address the most important things Unless evaluation priorities, system requirements tend to expand as users make more suggestions (called “scope creep”)
Prototype for Feasibility and Discovery
• If system involves new technology, the team may need to get experience working with it. Creating prototypes can be very valuable • • • • Prototyping helps to understand possibilities and limitations of the technology Good idea for projects where requirements are hard to define beforehand By showing prototypes to end users can get feedback into what is really needed Prototypes help users (and analysts) to discover requirements they might not thought about otherwise, i.e. think creatively 6
The Analysis Phase
Generate and Evaluate Alternatives
• Could include considering more than one method to develop system • • • Could involve in-house development or outsourcing to a consulting firm Might be able to use “off the shelf” software package Each alternative has costs and benefits to be considered • Also must consider technical feasibility
Review Recommendations with Management
• Usually done when all the above are completed • • • Must decide if project should continue at all Must decide on which alternative is best (if you are going ahead with the project) NOTE: at this point should include an option
Possible reasons CANCELLATION
of the project as • • • May have found costs were too high May have found benefits were lower than thought 7
Activities of the Analysis Phase and Their Key Questions
8
System Requirements
System requirements
that define the functions of the new system – specifications Two sets of requirements:
Functional
requirements
Nonfunctional
requirements 9
Functional requirements
Functional requirements
Activities system must perform (use cases) Based on procedures and business functions Documented in analysis models E.g.: “reduce fuel costs by calculating where is it best to fuel up” 10
Nonfunctional requirements
Nonfunctional requirements
Technical requirement – hardware and software Performance requirement – workload measures Usability requirement – user interface, workflow Reliability requirement – outages, error detection Security requirement – access & protection E.g.: “the new system must be run in a client server environment with Windows NT”, “must have one second response time” 11
Models and Modeling
Requirements are describes by a collection of models Complex systems require more than one type of model Models represent some aspect of the system being built Process of creating models helps analyst clarify and refine design Models assist communication with system users 12
Reasons for Modeling
13
Types of Models
Different types of models are used in information systems development
Mathematical
– formulas that describe technical aspects of the system (e.g., processing rules)
Descriptive
– narrative memos, reports, or lists that describe aspects of the system
Graphical
– diagrams and schematic representations of some aspect of the system 14
Some Descriptive Models
15
Overview of Models Used in Analysis and Design
Analysis activities named “define system requirements” Logical models Provide detail without regard to specific technology (
perfect technology assumption
) Design models Physical models Provide technical details (
non-perfect technology assumption
) Extend logical models 16
Models Created During Analysis
17
Stakeholders—The Source of System Requirements
People with interest in successful system implementation Three primary groups of
stakeholders
Users (use system) Clients (pay for and own system) Technical staff (ensure system operation) Every type of stakeholder is identified by analyst - one of the most important first steps in determining systems requirements The second task is to identify the critical person from each stakeholder type to be available as the business expert.
18
Stakeholders Interested in New System Development
19
Users as Stakeholders
Horizontal users (i.e., across departments) Vertical users or hierarchy within a department (i.e., clerical staff, middle management, and senior executives )
Business users
– perform day-to-day operations (
transactions
): provide information about daily operations and how system supports them
Information users
- who need current information
Management users
information
Executive users
– who need summary – who need strategic information
External users
via Internet) may have access to system (e.g., 20
Clients and Technical Staff as Stakeholders
Client Stakeholders
• They pay for the project so they are important!
• Project team must provide project status reviews to the clients
Technical Stakeholders
• The technical staff includes people who establish and maintain the computing environment of the organization • They are source of many technical requirements – provide guidance in such areas as programming language, computer platform, equipment, etc. 21
RMO Stakeholders
22
Techniques for Information Gathering
Analysis phase done to understand business functions and develop system requirements Original structured approach Create physical and logical models of existing system Derive requirements from existing system model Create physical and logical models of new system Current approach Identify logical requirements for new system Balance the review of current business functions with new system requirements 23
Traditional Approach to Identifying System Requirements
24
Current Approach to Identifying System Requirements
25
The transition from information gathering to model building
26
Methods of Information Gathering
Distribute questionnaires to stakeholders Review existing reports, forms, and procedure descriptions Interview and discuss processes with users Observe and document business processes Build prototypes Conduct sessions
joint application design
Research vendor solutions (JAD) 27
Just For Fun
28
Question Topics
• • What kind of information are we looking for during information gathering?
We need to obtain information that will enable us to build the
logical model
of the new IS • • • What Are the Business Processes? – i.e. understanding of business functions, building a comprehensive list of all the business process (focus on the current system).
How is the Business Processes Performed? – i.e., focus on how the new system should support the functions (visualize new and more efficient approaches to performing the business processes by new system) What Information is required? – i.e., elaboration of the second information in terms of defining specific information that the new system must provide.
29
Themes for information-gathering questions
30
Review Existing Reports, Forms, and Procedure Descriptions
Serves two purposes:
Provides a preliminary understanding of processes involved in a company Can be useful in conjunction with interviews Can be used to develop interview questions Can be used in interviews themselves (as visual aids and as working documents for discussion Helps to identify business rules that may not come up in the interview Helps to discover discrepancies and redundancies Can be extended to looking at other types of documents like emails, memos, etc 31
Sample Order Form for RMO
32
Conduct Interviews and Discussions with Users
One of the most effective ways to understand business functions and rules Can be time consuming and resource expensive Team members meet with individuals or groups of users May require multiple sessions to Meet all users Understand all processing requirements List of detailed questions prepared Can involve new approaches (
critical incident method cognitive task analysis
– not mentioned in text) To be effective should be organized in three areas: (1) preparing for the interview (2) conducting the interview (3) following up the interview and 33
Sample Checklist to Prepare for User Interviews
34
Preparing for the Interview
Must establish objective – what do you want to get out of it?
Determine users Could interview users with different levels of experience, computer expertise, bank expertise… Good to have at least two project team members at the interview Can compare notes in order to ensure accuracy Prepare detailed questions Good to structure the questions Can include both
open-ended
(e.g. “how do you do this function?”) and
closed-ended
questions (“how many times a day do you do this?”) Last step in preparing: make the interview arrangements (where to meet and when – good to pick a quiet room). Each participant should know the objective of the meeting, have a chance to preview the questions or materials to be reviewed 35
Conducting the Interview (1 of 2)
See text for variety of tips: like dress well, be polite and arrive on time!
Limit the time of the interview (plan for about an our and a half) If it is required more time to cover all questions, schedule another session. It is better to have several shorter interviews than one long “marathon” Look for errors or exception conditions – e.g. get them to describe when things go wrong (“What if it doesn’t arrive?”, “What if the balance is incorrect?”) In
critical incident method
case, as well as a “scenario from hell” “What ifs” can be explored as well as probing about real incidents experience can ask to describe an easy The ability to think of the exceptions is very important; it couldn’t be learned from a textbook, but only from 36
Conducting the Interview (2 of 2)
Probe for details In addition to looking for exception conditions, the analyst must probe to get a
complete understanding
of procedures and rules It is easier to get general overview than details on how it works and what information is used Take careful
notes
(it provides the basis for the next interview) Try to follow some
logical agenda
interview). during the interview (it helps to prod your memory on issues and items that should be discussed in an 37
Sample Agenda for Interview
38
Following Up the Interview
The first task is to absorb, understand and
document
the information collected from the interview Can write it up as text and also document by constructing diagrammatic
models
of business processes
Review
results with others who attended the interviews (within a day or at most two) Make a list of questions that need further elaboration (
open-items list
) Make a list of
new questions
based an areas that need more elaboration or that are missing information Send a thank-you note or email to the users who participated in the interview 39
A Sample Open-Items List
40
Observe and document business processes (1 of 2)
Varies from office walkthroughs to performing actual tasks Not necessary to observe all processes at same level of detail May make users nervous, so use common sense Can document workflows with UML activity diagrams 41
Observe and document business processes (2 of 2)
Early in the investigation activities, time should be scheduled to observe the business procedures in the organization that the new system will support Excellent way to learn how people do their jobs what problems they may have how to improve any systems they are using Can consist of Quick walkthrough of the office or plant Scheduling several hours to observe a user doing a real task (“day in the life”) Doing the task yourself to see what is involved 42
Documenting
A
workflow
handles one business transaction) is an effective way to capture information (sequence of processing steps that completely
Activity diagram
is a type of workflow diagram that describes the user activities and their sequential flow
Synchronization bar
– symbol to control splitting or merging of a path on an activity diagram
Swimlane
– bounded area that contains activities of a single agent
Sample
It represents a customer requesting a quote from a salesperson If it is a simple request, the salesperson can enter the data and create the quote If it is a complex request, the salesperson requests assistance from a technical expert to generate the quote In both cases, the computer system calculates the details of the quote 43
Activity Diagram Symbols
44
Activity Diagram that Models a Workflow
45
Activity Diagram with Concurrent Paths
46
Building Prototypes
Prototype
is an initial working model of a larger, more complex system Used for many purposes: To test feasibility To help identify processing requirements To compare different design and interface alternatives Different names to describe different uses Throwaway prototypes Discovery prototypes – used in the analysis phase for a single discovery objective and then discarded once the concept has been tested Design prototypes – used in the design phase to test various design alternatives Evolving prototypes – prototypes that grow and evolve and may be used as the final, live system 47
Prototypes
Characteristics of Prototypes:
Operative
: a prototype should be a working model, with some real functionality (if not working, but just shows what it looks like, its called a
mock-up
)
Focused Quick
process) : a prototype should be focused on a single objective (to test a specific concept or verify an approach) : the prototype should be built and modified quickly (so can validate an approach, and if it is wrong, fix it fast in an iterative
Distribute and Collect Questionnaires
Have a
limited
and specific use Allow to collect information from a
large number
of stakeholders Can be used to get a
preliminary insight
information needs of the various stakeholders Not well suited for gathering
detailed
on the information Three groups of questions:
Quantitative
(e.g., “How many customers a day?”)
Closed-ended Open-ended
(express opinion on a predetermined scale: ““On a scale of 1 to 10 rate system performance” ) - direct respondent, simple and short answer is assumed; easy to tabulate and process - encourage discussion and elaboration, no predetermined answer 49
quantitative Sample RMO Questionnaire Closed-ended open-ended
50
Conduct Joint Application Design Sessions
Expedites investigation of system requirements
JAD
is a technique to define system requirements in a single session by having all the necessary people participating together
Compare:
Normal interview and discussion approach takes a lots of time and effort (meet with users, document the discussion, build models, review and revise them, place unresolved issues on an open-items list – all of those on iterative basis!)- May require many meetings (months)
JAD idea
is to compress all these activities into a shorter series of meetings with users and team members (An individual JAD session may last from a day to a week)
Critical factor
is to have all important stakeholders present 51
Joint Application Design Participants
JAD session leader
Trained in group dynamics and facilitating group discussion Must ensure agenda and objectives are met Often system analyst appointed as leader but better if someone actually trained to lead group decision making May not be the expert in the business area though
Users
Managers are good to have at the meeting since important decisions have to be made If executives cannot be at the meeting, they at least should be contactable (or visit once a day)
Technical staff
A representative from the technical support group should be present (e.g. for info. regarding networks, operating environments etc.)
Project team members
System analysts User experts Assist in discussion, clarify points, build models and document the results Members of the project team are the experts on ensuring the objectives are met 52
Joint Application Design Facilities
Conducted in special room
Limit interruptions May be off-site
Resources
Overhead projector, white board, flip charts, work material Electronic support (laptops) CASE tools Group support systems (GSS) 53
A JAD Facility
54
Group Support Systems (GSSs)
System that enables multiple people to participate with comments at the same time, each on his or her computer • • • • Allows for sharing of information and collaborative work Runs on networked computers Can include “chat” features to allow posting to participants Allows inclusion of “shy” participants • • Can store results of discussion and decisions made Also allows for connection with participants at distant locations – a “virtual” meeting (could include video hookup) Other forms of electronic support • • Electronic white boards
C
omputer
s
upport for
c
ollaborative
w
ork (
CSCW
) software • Would allow for participation at remote sites who could work on documents at same time (shared files, etc.) 55
Limitations of JAD
Can be
risky
Since done very fast may end up with
sub optimal
decisions Details may be inappropriately defined or missed However, can be effective if it is done carefully with the result of shortening the schedule 56
Research Vendor Solutions
Many problems have been solved by other companies Positive contributions of vendor solutions Frequently provide new ideas May be state of the art Cheaper and less risky Danger May purchase solution before understanding problem 57
Useful Techniques in Vendor Research
Technical specifications from vendor Demo or trial system References of existing clients On-site visits Printout of screens and reports
58
Validating the Requirements
Make sure gathered information is correct (fixing a requirements error later in SDLC can cost hundreds of times more than it would have cost to fix it during the requirements definition!) In software development, each project is unique, so each set of system requirements should be reviewed and tested as much as possible In programming we can proof the accuracy of the code using tests (i.e. by executing the program by entering appropriate input data and observing the resultant output. We cannot test the requirements that way In system analysis jargon it is called
verify
and
validate
(
V&V
) the system requirements • •
Verification Validation
means determining that the requirements are internally consistent (test whether the field definitions are consistent throughout all of the subsystems of a system) means ensuring that the requirements are complete and correctly express users’ needs
Structured walkthrough
is effective means of implementing quality control early in project 59
Structured walkthrough
• Reviewing of the
findings
investigation Reviewing of the findings
models
from your based on those This approach is analysts formalize the review process into a set procedure
structured
because
Objectives:
project team to find errors, omissions and problems by documenting the requirements as the analysts understand them and then reviewing them with the It is not a performance review! 60
Structured walkthrough
What and When
First item to review is developed as part of the analysis phase. It can be: – A – A
narrative flow chart documentation
describing a process that was showing a workflow or model diagram documenting an entire procedure Better to conduct several
smaller
walkthroughs every week or two, than bigger ones with reviewing a number of documentation Very important to be scheduled as soon as documents have been created!
61
Structured walkthrough
Who
Two main parties involved in walkthroughs: – Person (or persons) who need their work to be reviewed – Group who reviews it It is best to have experienced
analysts
have seen lots of problems before!
involved in the walkthrough who reviews the documentation especially for verification since they For validation good to have
stakeholders
Could also include
technical staff
, or even whoever is best for validating the work involved
external users
–
How
Requires the same steps as an interview (i.e., preparation, execution and follow-up)
Preparation:
material The analyst whose work is to be reviewed should: – Get materials ready for review – Identify appropriate participants and provide them copies of the – Schedule a time and place and notify all participants 62
Structured walkthrough
Execution
– During the walkthrough analyst presents material point by point – Walks through each diagram or section of a document explaining each component (one effective technique is to define a sample test case and process it through the defined flow) – The reviewers look for inconsistencies or problems and point them out – A librarian (helper for presenter) documents the comments, errors and suggestions – Corrections and solutions are not made during the walkthrough – If there is a complex error may reschedule for another meeting – Reviewer should only provide focused feedback – Presenter can integrate feedback later on when gets entire set of comments
Follow-up
– Making required corrections – Additional walkthrough may be needed 63
Structured Walkthrough Evaluation Form
64
Readings
Today’s lecture: Chapter 4 – “Investigating System Requirements” For next lecture: Chapter 5 – “Modeling System Requirements” 65