Csc 375 Midterm

Front 1

Systems Analysts do what?

Back 1

1. Define the problem
2. Understand the problem
Gather and analyze requirements
3. Evaluate possible solutions
4. Design a solution

Front 2

The Systems Development Lifecycle

Back 2

planning, defining, designing, building, testing, deployment

Front 3

The Agile Approach

Back 3

exploration, planning, iterate until first release, production/maintenance

Front 4

Effective Meetings

Back 4

1. Achieve an objective that cannot be doneusing other means

2. Take up minimum amount of time

3. Involve the right people

4. Leave participants feeling it was a goodway to spend their time

Front 5

Request for Proposals

Back 5

Captures the Clients’ expression of a need for improvementand defines the project

Front 6

Sections of an RFP

Back 6

Project Overview

Project Objectives

Context

Schedule, Constraints

Client team and contact info

Glossary

Front 7

Why is a Project Charter important?

Back 7

• Sets realistic expectations

• Everyone on same page

• Defines clearly what will be done/not done

• Gives a name to the project & defines uniqueterms

• Guides the project

Front 8

Project Charter

Back 8

Captures the problem and what will be doneabout it

Front 9

Sections of a project charter

Back 9

1. Overview

Executive summary, Context, Need, Scope, Stakeholders, Objectives, Glossary

2. Approach

Team organization and roles, Work Breakdown Structure, Milestones, Deliverables, Risks

3. Approval

Front 10

Main Elicitation techniques

Back 10

Background reading/inspection of documents

• Interviews (open ended or structured)

• Questionnaires

• Observations

• Group techniques (JAD, Participatory design,focus groups)

• Contextual Design

Front 11

Five steps of an interview:

Back 11

Preparing for the interview

Planning and scheduling the interview

Opening and closing the interview

Conducting the interview

Following up for clarification

Front 12

Structured interviews

Back 12

Advantages

1. Forces an organization on the interview

2. Very goal-directed

3. Attempts to remove distortion from interviewees subjectively

4. Allows better integration of material after the interview

5. Forces the interviewee to be systematic

6. Requirements engineer identifies gaps in the knowledge which acts as a basis for questions

7. Purpose of session is clear to interviewee

Disadvantages

1. Needs more preparation by the requirements engineer

2. Needs to study background material extensively

3. May overconstrain the interviewee, preventing discovery ofrequirements

4. May intimidate the interviewee

Front 13

Unstructured interviews

Back 13

Advantages

1. Appropriate when the RE wants to explore an issue

2. Facilitates description of domain in a way that is easy for the interviewee

3. Goal is to establish rapport and to get a broad view

Disadvantages

1. Data acquired is often unrelated and difficult to integrate

2. Often exhibits lack of structure

3. Does not allow gathering of specific knowledge

4. Takes time and training to do well

5. Similar questions asked in future sessions may annoy interviewee

Front 14

Interviews summary

Back 14

Advantages

– Access to individual stakeholders and their opinions

– Rich collection of information

– Ability to adapt questions to particular situations

Disadvantages

• Information from multiple sources, hard to analyze

• Difficult to be a skilled interviewer

• May intimidate the interviewee

Front 15

Questionnaires

Back 15

Advantages

– Ability to reach a large pool of people

– Uniformity of questions

– Geographical distribution of stakeholders not an issue

Disadvantages

– Difficult to collect contextual information

– Difficult to design well

Front 16

Observations

Back 16

Advantages

– Ability to collect contextual information

– Reveals details of tacit knowledge

Disadvantages

– Often difficult to obtain access to the customer site

– Time consuming

– Does not collect information on personal opinions

– Easy to “go native”

Front 17

Group techniques

Back 17

Advantages

– Bring stakeholders together!

– More informal interaction than interviews

Disadvantages

– More difficult to deal with groups, needs a trained facilitator

– Risk of groupthink

Front 18

Creating a Plan

Back 18

• People – leader, analysts, developers

• Milestones– Define tasks to reach each milestone

• Assign people to tasks

• Estimate task duration

• Dependencies between tasks

• Check sanity & adjust

Front 19

Managing risks

Back 19

• Create a list of risks

• Assign each a severity (impact) andprobability• How to cope with each risk?– Add coping strategies as tasks

Front 20

Hard vs. soft systems

Back 20

No human interaction
vs
Human interaction

Front 21

Functional vs. non-functional

Back 21

• Functionality

• Physical environment

• Interfaces

• Users and human factors

• Documentation

• Data

• Resources

• Security

• Quality assurance

Front 22

Functionality

Back 22

What will the system do?

• When will de system do it?

• Are there several modes of operation?

• How and when can the system be changed orenhanced?

Front 23

Users and human factors

Back 23

• 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 eachtype of user?

• How difficult will it be for a user to misuse thesystem?

Front 24

Data

Back 24

• For both input and output, what should theformat or the data be?

• How often will they be received or sent?

• How accurate must they be?

• To what degree of precision must the calculationsbe made?

• How much data flow through the system?

• Are there confidentiality concerns about the data?

Front 25

Physical environment

Back 25

• Where is the equipment to function?

• Is there one location or several?

• Are there any environmental restrictions,such as temperature, humidity or magneticinterference?

Front 26

Interfaces

Back 26

Is the input coming from one or more othersystems?

• Is the output going to one or more other systems?

• Is there a prescribed way in which the data must beformatted to effectively interface with othersystems?

• Is there a prescribed medium that the data must use(e.g. reports by mail, meetings, website)?

Front 27

Documentation

Back 27

How much documentation is required?

• Should it be on-line in book format orboth?

Front 28

Resources

Back 28

• What materials, personnel, or other resources arerequired to build, use, and maintain the system?

• What skills must the developers have?

• How much physical space will be taken up by thesystem?

• Is there a prescribed timetable for development?

• Is there a limit on the amount of money to be spent ondevelopment or on hardware and software?

Front 29

Security

Back 29

Must access to the system or information becontrolled?

• How will one user's data be isolated fromothers?

• How will user programs be isolated from otherprograms and from the operating system?

• How often will the system be backed up?

Front 30

Quality assurance

Back 30

What are the requirements for reliability, availability,maintainability, security?

• What is the prescribed mean time between failures?

• Is there a maximum time allowed for restarting thesystem after a failure?

• What efficiency measures will apply to resource usageand response time?

Front 31

What makes a SRS high quality?

Back 31

Unambiguous

• Complete

• Verifiable

• Consistent

• Modifiable

• Traceable

• Ranked for importance

• Correct

Front 32

Sources of non-functional requirements

Back 32

• Project charter

• Your interview notes

• Use cases

• UI Prototype development

• Business processes

• Explicit interviews or questionnaires

Front 33

How to write good non-functional reqs?

Back 33

• Must be testable

Front 34

Agile vs. “traditional” Modeling

Back 34

The “agile”: A practical method formodeling to create software systems

• Based on best practices

• Light-weight– ‘just enough’ to get the job done– don’t model for the sake of modeling

Front 35

Use Case Modeling

Back 35

interaction between actors
each use case can be a subset of large diagram

Front 36

Domain Modeling: Entity RelationshipDiagrams

Back 36

1 to 1
1 to many

Front 37

The use case specification should include

Back 37

Actors – primary, possibly secondary

• Preconditions – What has to have happenedfirst

• Steps (numbered and may have sub-steps)– List the actions of the actor

• Success condition – What has to result for thisto be successful

• Alternate paths (if any)– Branch off at the appropriate numbered step

Front 38

Data Flow Diagram

Back 38

verbs are in bubbles
connections just describe data

Front 39

Context Diagram(DFD 0)

Back 39

• The highest level in a data flow diagram

• Contains only one process, representingthe entire system

• The process is given the number 0

• All external entities, as well as major dataflows are shown

Front 40

DFD 1

Back 40

drilldown into system in DFD 0
box around parts

Front 41

Typical errors in a data flow diagram

Back 41

process has no output
process has no input

external entity should not correct directly to data store

data store does not connect directly to data store