BUS 394 - Topic 3 Flashcards
Requirements Documentation - Analysis Phase
Analysis Phase
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)
Key activities of the analysis phase
Information gathering
documentation
modeling
requirement
a statement specifying a feature or characteristic that the system should have for the project to be considered successful
Requirement definition: Feature vs Characteristic
- 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.
Are requirements a deliverable?
Requirements can be a deliverable, but are typically used as ingredients to
other deliverables (Use cases, DFDs, UI mockups, etc.)
Why gather requirements?
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
Two main types of requirements:
functional and non functional
functional requirements
Features
can be stated with a user or system focus
- “User needs to…”
- System needs to …”
Non- functional requirements
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?
Hierarchy of requirements
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
examples of organizational methods for requirements:
Numbering
- 1, 1.1, 1.2, 1.2.1
Outline/ Bullets
Goals in gathering requirements
Complete, Clear, Correct, and meaningful
methods for gathering requirements
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