BUS 394 - Topic 3 Flashcards

Requirements Documentation - Analysis Phase

1
Q

Analysis Phase

A

defines the requirements of the system, independent of how these requirements will be accomplished

  • you must define the problem (analysis) before you can determine the solution (design)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

Key activities of the analysis phase

A

Information gathering
documentation
modeling

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

requirement

A

a statement specifying a feature or characteristic that the system should have for the project to be considered successful

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

Requirement definition: Feature vs Characteristic

A
  • Feature - something the system should be able to do or allow the user to do
  • Characteristic - attribute of the system as a whole, such as its speed,
    language, security, etc.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

Are requirements a deliverable?

A

Requirements can be a deliverable, but are typically used as ingredients to
other deliverables (Use cases, DFDs, UI mockups, etc.)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

Why gather requirements?

A

Before you can design the system, you need to fully understand what is required.

  • An undocumented requirement can be devastating to a project.
  • Often, the customer (or department) doesn’t know what they want. Thus, it’s imperative to figure things out early, in order to avoid potential disputes down the road
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

Two main types of requirements:

A

functional and non functional

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

functional requirements

A

Features
can be stated with a user or system focus
- “User needs to…”
- System needs to …”

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

Non- functional requirements

A

characteristics

Can be anything, but typically fall into certain categories:
- Security - who has access to what?
- Performance – how does the system need to run?
- Aesthetic/Branding – what does the system need to look like?
- Cultural/Political – what outside factors must the system incorporate?
- Operational – what physical/technical environment will the system be entering?

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

Hierarchy of requirements

A

A _____ can allow low level requirements to be connected to their corresponding high level requirements.
requirements are often documented at different levels depending on the level of detail

can be sorted into high- level/ low - level reqs
- high level = more detailed
- low level = less detailed

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

examples of organizational methods for requirements:

A

Numbering
- 1, 1.1, 1.2, 1.2.1

Outline/ Bullets

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

Goals in gathering requirements

A

Complete, Clear, Correct, and meaningful

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

methods for gathering requirements

A

interviews, surveys, JAD sessions, Observation, Document Analysis, Focus group, reverse engineering

Minor improvements
 Root cause analysis

Moderate improvements
 Brainstorming
 Process Analysis

Major improvements
 Outcome Analysis
 Technology Analysis
 Activity Elimination

How well did you know this?
1
Not at all
2
3
4
5
Perfectly