Determining system requirements

advertisement

Asper School of Business

University of Manitoba

Systems Analysis & Design

Instructor: Bob Travica

Determining systems requirements

Updated: September 2014

Outline

System analyst’s job

Concept of system requirement

Modeling requirements via diagrams

Requirements gathering methods

(Interviewing, Focus Groups, Observation,

Think–Aloud Protocol, Joint Application Design,

Survey)

3510 Systems Analysis & Design * Bob Travica 2 of 14

Requirements activity in SDLC

Requirements collected in each iteration; most of it is in

Elaboration phase.

needs .

Requirements activity precedes design, implementation, testing… In the end of each iteration (a column) is working software, whose development can be continued later.

3510 Systems Analysis & Design * Bob Travica 3 of 14

Systems analyst’s job

Define & document system requirements (functional & nonfunctional):

Investigate user needs (interview, etc.)

Understand business (application domain)

Study existing system (hands-on, documentation, inputs/outputs)

Study b enchmark systems

Create diagrams & descriptions to capture requirements

 that will translate into system’s data model and functionality

Model user interface

3510 Systems Analysis & Design * Bob Travica 4 of 14

System Requirements

Functional: Specification of tasks system should perform (e.g., calculate pay)

Non-functional:

User interface (e.g., ease of use)

Technical performance (e.g., execution speed, reliability)

Security…

3510 Systems Analysis & Design * Bob Travica 5 of 14

Object-oriented diagrams

Activity

Diagram

3510 Systems Analysis & Design * Bob Travica 6 of 14

Requirements gathering methods

Interviewing

Focus Groups

Observation

Think–Aloud Protocol

Joint Application Design

Survey

3510 Systems Analysis & Design * Bob Travica 7 of 14

Interviewing

• Data collection through talking with users

• Natural, pervasive, basic method

• Good example: Consultants developing custom software, multiple visits, working with client

Bad example: Too short interviewing, biased user samples, inappropriate outsourcing of interviewing task

• Considerations:

• Communication issues

• Level of structuring (open-ended vs. close-ended)

• Time expenditures

• Advantages: Can provide specific & rich account of needs

• Challenges: Striking a right balance between considerations

3510 Systems Analysis & Design * Bob Travica 8 of 14

Interviewing example

Theme

What tasks and processes are involved?

How are the tasks and processes performed?

How should they be?

Questions to ask users

• What do you do usually at work?

• How do you do your work?

• Can you describe any steps you may need do take?

• Anything you’d like to change to make your work easier or better?

What are the informing needs of this user?

• What documents do you use at work?

Any communications you use daily?

• Is there anything you feel missing?

Focus Groups

• Group interviewing with many interviewers

• Origin: Marketing research

• Example Designing campus wise IS at Syracuse Univ.

• Example Untrained interviewers, weak analysis of focus group data. Usually not obvious immediately.

• Considerations:

• Discussion focus

• Time distribution (talkative vs. silent interviewees)

• Advantages: Deep initial insight in user situation.

• Challenges: Managing group dynamics

3510 Systems Analysis & Design * Bob Travica 10 of 14

Observation

• Collecting data by watching, listening and asking spontaneous questions with various degrees of the observer’s visibility.

• Example Designing a database for a music store in NY

• Example Observers incapable of reading body language, speaking technical lingo, acting as authority

• Considerations:

• Involvement in user situation

• Subjectivity

• Obtrusiveness

• Advantages: Learning in natural context, rich in detail.

• Challenges: Hawthorne effect (negative effect from obtrusiveness), validity of conclusions

3510 Systems Analysis & Design * Bob Travica 11 of 14

Think-Aloud Protocol

• Recording users’ thoughts they speak aloud while performing a task with a system; “short memory “dump”

• Example Simulation systems for risky situations (pilots)

• Example Lack of prompting users to speak

• Considerations: Relaxing the user to talking along with doing

(not a natural behavior)

• Advantages: Insight in user’s short-term memory that otherwise may be lost

• Challenges: User’s account may be narrow and not reflexive

(thought-through)

• Can be combined with observation (in usability study)

3510 Systems Analysis & Design * Bob Travica 12 of 14

Survey

• Collecting mostly quantitative data by administering a questionnaire (mail, or electronic).

• Example Quick probing a general feeling about an existing system & a need for new sys. User satisfaction.

• Example Asking too specific & too many questions, anonymity issue

• Considerations : Limitations of written communication

• Advantages: Specific coverage and time savings, electronic trail (direct entry of answers to database)

• Challenges: Validity of users’ responses and lower response rates

3510 Systems Analysis & Design * Bob Travica 13 of 14

Joint Application Design

A JAD Facility

• Discussion in a small group (designated team, committee) until job is done.

Example: IBM

3510 Systems Analysis & Design * Bob Travica 14 of 14

Download