ITEC 3010 Lecture 4 Investigating System Requirements - PowerPoint PPT Presentation

Loading...

PPT – ITEC 3010 Lecture 4 Investigating System Requirements PowerPoint presentation | free to download - id: 713423-NmVjN



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

ITEC 3010 Lecture 4 Investigating System Requirements

Description:

Title: Requirements Specification Author: Andre Kushniruk Last modified by: luiz Created Date: 9/21/2000 2:50:40 AM Document presentation format: On-screen Show (4:3) – PowerPoint PPT presentation

Number of Views:91
Avg rating:3.0/5.0
Slides: 58
Provided by: Andre756
Learn more at: http://www.yorku.ca
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: ITEC 3010 Lecture 4 Investigating System Requirements


1
ITEC 3010 Lecture 4 Investigating System
Requirements
2
Analysis Phase Activities
  • Gather Information
  • Involves gathering lots of information
  • Can get information from people who will be using
    the system
  • By interviewing them
  • By observing them
  • Can get other information by reviewing documents
    and policy statements (e.g. At a bank)
  • Can involve the analyst actually doing some or
    part of the task to get a feel for what is done
  • In order to automate order-entry you may need to
    become an expert on the task (knowing how
    orders are processed)
  • Need to understand current and future users,
    locations, system interfaces, possible solutions,
    etc.

3
  • Define System Requirements
  • Involves modelling
  • Logical Model
  • Any model that shows what the system is required
    to do without committing to any one technology
    requirements model is logical
  • Physical Model
  • Any model that shows how the system will actually
    be implemented
  • Models are often graphical in nature
  • Data flow diagrams (DFDs)
  • Entity-relationship diagrams (ERDs)
  • Natural Language is ambiguous

4
(No Transcript)
5
  • Prioritize Requirements
  • Important to establish which functional and
    technical requirements are most critical
  • Why? Since resources are always limited and you
    want to address the most important things
  • If not addressed can lead to scope creep, where
    the scope of the project just seems to expand
    over time

6
  • Generate and Evaluate Alternatives
  • Could include considering more than one method to
    develop system
  • Could involve in-house development or outsourcing
    to 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

7
  • 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 CANCELLATION
    of project as an option
  • May have found costs were too high
  • May have found benefits were lower than thought
  • Maybe the business environment suddenly changed
    making the project obsolete
  • Detailed documentation has been collected
  • System requirements
  • Proposed solution

8
(No Transcript)
9
Requirements Specification
  • Requirement specification results from Analysis
    phase
  • What is a requirement?
  • A feature of the system or description of
    something the system is capable of doing to
    fulfill the systems purpose
  • It addresses the purpose of the system (i.e. What
    it is supposed to do) and not how it will be
    implemented (However, Non-Functional requirements
    might require the analyst to look closer to how
    it will be implemented)

10
Functional and Technical Requirements
  • Functional Requirements
  • A system requirement that describes a function or
    process that the system must support
  • E.g. system will calculate tax amounts, report
    year end tax deductions
  • Non-Functional Requirements / Technical
    Requirements
  • A system requirement that describes an operating
    environment or performance objective. Describe
    constraints on functional requirements
  • E.g. Tax amounts should be accurate, Calculate
    Tax amount should be easy to use
  • Security
  • Safety
  • Privacy

11
Summary of Types of Requirements
PHYSICAL ENVIRONMENT
INTERFACES
USER AND HUMAN FACTORS
QUALITY ASSURANCE
Requirements
FUNCTIONALITY
SECURITY
DOCUMENTATION
DATA
RESOURCES
12
Types of Requirements/Questions Asked
  • Physical Environment
  • Where is the equipment to function?
  • Is there one location or several?
  • Are there any environmental restrictions such as
    temperature, humidity or magnetic interference?
  • Interfaces
  • Is the input coming from one or more systems?
  • Is the output going to one or more systems?
  • Is there a prescribed way in which the data must
    be formatted?
  • Is there a prescribed medium that the data must
    use?

13
  • Users and Human Factors
  • Who will use the system?
  • Will there be several types of users?
  • What is the skill level of each type of user?
  • What kind of training will be required for each
    type of user?
  • How easy will it be for a user to understand the
    system?
  • How difficult will it be for a user to misuse the
    system?

14
  • Functionality
  • What will the system do?
  • When will the system do it?
  • How and when can the system be changed or
    enhanced?
  • Are there constraints on execution speed,
    response time, or throughput? (Non-Functional
    Req. frequently associated with FR)
  • Documentation
  • How much documentation is required?
  • To what audience is the documentation addressed?

15
  • Data
  • For both input and output, what should be the
    format of the data?
  • How often will it be received or sent?
  • How accurate must it be?
  • To what degree of precision must the calculations
    be made?
  • How much data flows through the system?
  • Must the data be retained for any period of time?
  • Resources
  • What materials, personnel or other resources are
    required to build, use and maintain the system?
  • What hardware is required?
  • What software is required? (eg. Databases?)

16
  • Resources (continued)
  • What skills must the developers have?
  • How much physical space will be taken up by the
    system?
  • Is there a prescribed timetable for development?
  • Is there a limit on the amount of money to be
    spent on development or on hardware and software?

17
  • Security
  • Must access to the system or to information be
    controlled?
  • How will one users data be isolated from
    others?
  • How will user programs be isolated from other
    programs and from the operating system?
  • How often will the system be backed up?
  • Must the backup copies be stored at a different
    location?
  • Should precautions be taken against fire or
    theft?

18
  • Quality Assurance
  • What are the requirements for reliability?
  • How the characteristics of the system must be
    demonstrated to others?
  • Must the system detect and isolate faults?
  • What is the prescribed mean time between
    failures?
  • Is there a maximum time allowed for restarting
    the system after a failure?
  • How can the system incorporate changes to the
    design?
  • Will maintenance merely correct errors, or will
    it also include improving the system?
  • What efficiency measures will apply to resource
    usage and response time?
  • How easy should it be to move the system from one
    location to another or from one type of computer
    to another?

19
Stakeholders The source of system requirements
  • Stakeholders People who have an interest in the
    success of the new system
  • The users who actually use the system
  • The clients who pay for and own the system
  • The technical staff who ensure the system runs
  • Must identify stakeholders
  • Cannot forget an important group e.g. users!

20
User Stakeholders
  • Can identify users horizontally i.e. Across
    departments
  • Can also identify users vertically i.e.
    Hierarchy within a department (e.g. lower, middle
    and upper managers)
  • Type of users
  • Business operations users use the system daily
    to perform operations (transactions a piece of
    work)
  • Query users could be business people or
    customers request info
  • Management users want reports, performance
    stats, want to know volumes of transactions etc.
  • Executive users want information to help with
    strategic issues, e.g. compare improvements in
    resource utilization

21
(No Transcript)
22
(No Transcript)
23
Stakeholders at Rocky Mountain Outfitters
  • Operational users of the new order system
  • Inside sales representatives (who take orders)
  • Clerks (who process order)
  • Warehouse workers
  • Each type of user has their own needs and
    preferences
  • Need usability testing to get at this! (text
    doesnt mention)
  • Project funded from internal cash flow
  • Since the system involves new technology
    (Internet) need involvement from technical staff

24
Identifying System Requirements
  • Main Objective of Analysis Phase
  • To understand the business functions and develop
    system requirements
  • Question of studying existing systems first or
    not
  • Using structured approach, analyst first
    documents the existing system then extrapolates
    the requirements of the new system
  • Approach
  • Develop current system physical models
  • Extract the current system logical models
  • Develop new system logical model
  • Develop new system physical model

25
  • Faster approach
  • Identify current system procedures immediately
    (as much as need to, dont necessarily define
    specific processes)
  • Develop requirements and models for new system
    (ie. develop logical model)
  • In either approach, need to balance investigation
    of old procedures with need to focus on
    requirements of the new system

26
Questions asked (overall)
  • What are the current business processes and
    operations?
  • Ask the users, What do you do ?
  • Assess what current functions can remain and
    which should be eliminated by technology
  • How should the business processes be performed?
  • Ask the user How can it be done?, What steps
    should be followed? (using the new system). How
    else ?
  • What information is needed?
  • Specific information requirements, e.g. Databases
    needed

27
Skills Needed and Methods Used
  • Understanding of user needs
  • Ability to analyze and solve business problems
  • Being able to identify and capture business rules
  • Methods
  • Distribute questionnaires to stakeholders
  • Review existing reports, forms and procedure
    descriptions
  • Conduct interviews and discussion with users
  • Observe business processes and workflows in real
    life (can video or audio record activities, do
    usability testing etc.)
  • Build prototypes
  • Conduct joint application design (JAD) sessions

28
Distribute and Collect Questionnaires
  • Allows to collect information from large numbers
    of users
  • Can obtain early insight into information needs
  • Can be useful for collecting demographic or
    quantitative information
  • e.g. how many orders do you enter a day?
    What is your educational background?
  • Can collect information using scales, e.g. On a
    scale of 1 to 7 how important is system speed?
    closed-ended questions which do not invite
    discussion
  • Less useful for collecting other types of
    qualitative information (e.g. system usability,
    user-interface needs)

29
(No Transcript)
30
  • Types of Questions in Questionnaires
  • Closed-ended questions (to determine quantitative
    information (Part I in figure 4-5)
  • Opinion questions (Part II in figure 4-5)
  • Requests for explanation or problems (Part III in
    figure 4-5)
  • Note some current use of questionnaires
  • Deployment over the WWW is easy
  • Can use text entry boxes for explanation or
    problems
  • Can automatically summarize questionnaire results

31
Limitations of Questionnaires
  • Not well suited for learning about processes,
    workflows or techniques (e.g. to answer How do
    you do this process? - better to interview or
    observe)
  • Questions that encourage elaboration are called
    open-ended can be put in a questionnaire but
    if there are too many of these, questionnaires
    tend not to get returned!
  • Relies in users memory of their use of systems
    (researches show this differs from what they
    actually do in many cases!)

32
Review Existing Reports, Forms and Procedure
Descriptions
  • Review of existing documents very useful
  • Can help you get a preliminary understanding of
    processes involved in a company
  • Can be used in conjunction with interviews
  • Can be used to develop interview questions
  • Can be used in interviews themselves
  • As visual aids
  • Working documents for discussion
  • Review of forms helps to identify business rules
  • Helps to discover discrepancies and redundancies
  • Can be extended to looking at other types of
    documents like emails, memos etc.!

33
(No Transcript)
34
Conducting Interviews and Discussions with Users
  • Interviewing stakeholders is one of the most
    effective ways to understand business functions
  • Can be time-consuming and resource expensive
  • A number of members of the project team meet with
    individuals (or groups of users)
  • List of detailed questions is prepared and
    discussion continues until all the processing
    requirements are understood
  • May involve multiple sessions (often does)
  • Can involve new approaches (Protocol analysis,
    Ethnography etc ITEC 4040)

35
Prepare
Carry out
Follow up
36
Preparing for the Interview
  • Must establish objective what do you want to
    get out of it?
  • Determining 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, but not more than three
  • Can compare notes
  • I like to audiotape interview (when allowed!)
  • 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?)

37
  • Last step in preparing make the interview
    arrangements (where to meet and when good to
    pick a quiet room)
  • Conducting the Interview
  • See text for variety of tips, like dress well, be
    polite and arrive on time!
  • Have to limit time of interview
  • Avoid marathon interviews
  • Look for error or exception conditions e.g. get
    them to describe when things go wrong
  • In critical incident method can ask to describe
    an easy case, as well as a scenario from hell
  • What ifs can be explored as well as probing
    about real incidents

38
  • Probe for details
  • In addition to looking for exception conditions,
    the analyst must probe to get a complete
    understanding of procedures and rules
  • Take careful notes
  • Text says tape recorders make people nervous, but
    notes and taping is good combo!
  • Privacy.
  • Try to follow some logical agenda during the
    interview
  • Semi-structured interviews often most useful
    (unstructured interviews can often get out of
    control)

39
(No Transcript)
40
Following Up the Interview
  • Have to absorb, understand and document the
    information collected from the interview
  • Can write it up as text and also document by
    constructing diagrammatic models
  • Review with others who attended the interviews
  • Make a list of questions that need further
    elaboration (see figure 4-9 for an example of a
    sample Open-items list)

41
Observing Business Procedures and Workflows
  • Early (but not too early) in the investigation
    should observe the activities in the organization
    as they really occur
  • 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)
  • More involved methods e.g. Videotaping the
    workplace and using methods from social science
    to analyze

42
  • When observing
  • Should attempt to be unobtrusive, so you dont
    change the users behaviour because you are
    watching them!
  • May require consent to do this (e.g. videotaping
    intensive care unit in a hospital)
  • May require repeated or extended observation
    periods to really understand what is going on
  • If you are observing (and not recording) then
    best to have more than one observer go along
  • As text mentions, common sense and sensitivity to
    needs and feelings of the users is VERY important!

43
Observing Activities some notes
  • Decide what is to be observed
  • Decide what level of detail should be looked at
    (how concrete the observation should be)
  • Create categories that capture key activities
  • Prepare materials for observation (forms to fill
    in for note taking)
  • Decide when to observe and what tools youll take
    (e.g. camera, tape recorder, or just recording on
    paper)
  • Decide on approach to sampling e.g. observe
    three one hour periods, or by event (e.g. board
    meetings)
  • Can be used in conjunction with other methods
    (e.g. interviews)
  • Could use forms to structure observations (see
    next slide)

44
Organziation Company Solid Steel
Shelving Analyst Joe Smith Scenario Quality
assurance Date 9/3/1999
  • Decision Maker (Actor) Observation of
    Information-Related Activity
  • Quality Assurance Manager - Asks
    shop floor supervisor for the days

  • production report.
  • Shop floor Supervisor -
    Prints out the daily computerized production

  • report.

  • - Discusses recurring problems in
    production

  • runs with quality assurance (QA)
    manger.
  • Quality Assurance Manager -
    Reads production report.

  • - Compares current report with other
    reports from

  • the same week.

  • - Observes on-screen results of QA
    model.


45
Building Prototypes
  • Prototype A preliminary working model of a
    larger system
  • Uses
  • To test feasibility
  • To help identify processing requirements
  • To compare different design and interface
    alternatives
  • Different names
  • Throwaway prototypes
  • Discovery prototypes used in analysis phase
  • Design prototypes used in design
  • Evolving prototypes
  • Prototypes that grow and eventually may end up
    becoming the final system

46
Prototypes as tools during Analysis
  • During analysis a discovery prototype
  • E.g. use of a prototype to determine screen
    formats and processing sequences (then thrown
    away)
  • Can show users or clients ideas early on to
    refine requirements (also used later on in design
    phase a lot)
  • Characteristics of Prototypes
  • Operative a prototype should be a working
    model, with some real functionality
  • Focused a prototype should be focused on a
    single objective
  • Quick the prototype should be built and modified
    quickly (so can validate an approach, and if it
    is wrong fix it fast in an iterative process)

47
Joint Application Design (JAD) Sessions
  • JAD a technique to define requirements or design
    a system in a single session by having all the
    necessary people participating together
  • Normal interviews take lots of time and effort
  • May require many meetings (months)
  • JAD idea why not compress all these activities
    into a shorter series of meetings with users and
    team members
  • JAD session may last a day to a week
  • Try to have all the stakeholders present to make
    decisions
  • All fact-finding, model-building etc. done in the
    JAD session

48
JAD 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)

49
JAD Participants - continued
  • Technical staff
  • A representative from the technical support group
    should be present (e.g. for info. regarding
    things like 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

50
Setting for JAD sessions
  • Usually conducted in special rooms
  • Off-site location may be good
  • But need access (phone etc.) to executives and
    technical staff not present
  • Resources
  • Overhead projector
  • Black or white board
  • Flip chart
  • Adequate work space

51
(No Transcript)
52
Advances to Support JAD sessions
  • Electronic support
  • Participants may have laptops connected in
    network
  • That way models and descriptions can be shown to
    everyone (could be done using a CASE tool)
  • Group Support Systems (GSSs)
  • System that enables multiple people to
    participate with comments at the same time, each
    on his or her computer
  • Allow 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 end up with a virtual
    meeting (could include video hookup)

53
  • Other forms of electronic support
  • Electronic white boards
  • Computer support for collaborative work (CSCW)
    software
  • Would allow for participation at remote sites who
    could work on documents at same time (shared
    files etc.)

54
(No Transcript)
55
Limitations of JAD
  • Can be risky
  • Since done very fast may end up with suboptimal
    decisions
  • Details may be inappropriately defined or missed
  • However, JAD can be effective if done carefully
    with the result of shortening the schedule

56
Business Process Reengineering (BPR)
  • Popular buzzword over last ten years
  • Due to global competition many companies have had
    to completely rethink their assumptions about how
    to do business
  • Old rule of business
  • If it isnt broken, dont fix it
  • Newer way of thinking
  • There is always a better way to do it, lets
    improve it
  • Business process reengineering approach
  • Lets question basic assumptions to find a
    completely new way to do it that will bring
    dramatic and profound improvement

57
Business Process Reengineering (cont.)
  • Objective to use IT in novel ways to achieve
    dramatic improvements in efficiencies and level
    of service
  • BPR and IT are closely aligned
  • Many systems analysts must also become business
    analysts
  • To assist in the process of rebuilding all
    internal business procedures based on new in
    innovative information technology
About PowerShow.com