Use LEFT and RIGHT arrow keys to navigate between flashcards;
Use UP and DOWN arrow keys to flip the card;
H to show hint;
A reads text to speech;
31 Cards in this Set
- Front
- Back
Requirements
|
are the description of the necessary and sufficient properties of a product that will satisfy the customer's need
|
|
Problem areas to watch out for to minimize defective requirements
|
Informal information gathering
Implied functionality Erroneous or un-communicated assumptions Inadequately defined requirements Casual change process |
|
System
|
a system is a collection of interrelated elements that work together to achieve an objective
|
|
System requirements
|
describes software capabilities of system as well as constraints on the system's implementation and operation
|
|
Why define requirements
|
Purpose - to deliver successful software product that meets users needs
|
|
Consequences of defective requirements
|
Cost overruns
Expensive re-work Poor quality Late delivery Dissatisfied Customers Exhausted and demoralized team members |
|
Verification
|
ensures you build the software correctly
|
|
Validation
|
ensures that you build the correct software - customer's need are met
|
|
Functional requirements
|
describes the product capabilities
-things the product must do for its users / allows its users to do -the actions, the tasks, and behaviours that users interact with |
|
Non- Functional requirements
|
properties that the product must have that may not be evident to the user
- |
|
Business requirements
|
WHY PROJECT IS BEING UNDERTAKEN
-describes the high-level purpose of the project and needs that the software must meet to increase revenue, increase profits, improve customer service, or meet regulatory obligations |
|
User requirements
|
WHAT USERS WILL BE ABLE TO DO WITH THE PRODUCT
describes the tasks that users need to accomplish any necessary quality characteristics |
|
System requirments
|
WHAT DEVELOPERS NEED TO BUILD
describes all the functional and non-functional requirements that the system must provide to meet the business and user needs. |
|
Project Initiation
|
where you create a common vision that defines the scope, stakeholders and goals - from a business point of view
produces deliverables that ensure successful requirement development and lay the groundwork for a successful project |
|
Vision statement
|
concise statement defining the what, why and who of the software end product from a business point of view
|
|
Purpose of the project
|
short statements of what is intended to be done; the benefits it brings to the business
|
|
Scope of the work
|
the business are to be improved
|
|
The stakeholders
|
the people with an interest in the end product
|
|
The constraints
|
the restrictions on the scope or style of the end product
|
|
The glossary
|
a dictionary of common terms relevant to the product being built, enhanced or equiped
|
|
Relevant facts and assumptions
|
any facts and assumptions that need to be known and that may affect the outcome of the project
|
|
The estimated cost
|
early estimates of costs from some of the deliverables
|
|
The risks
|
short risk analysis and mitigation strategy
|
|
Go/no go decision
|
decision based on whether the project is deemed viable - does the cost of producing the software make it worthwhile?
|
|
Rabbit projects
|
typically smaller projects with shorter lifetimes where close stakeholder participation is possible
|
|
Horse projects
|
typical corporate projects - most projects demand semi-formality. These typically have medium longevity
|
|
Elephant projects
|
typically in cases where the development is outsourced or the organizational structure dictates complete requirement specification. These typically have a long duration
|
|
The trinity of scope, stakeholders, and goals
|
To build the right product, you have to understand the extent of the work; the people who do it, influence it, or know about it; and the outcome that those people are trying to achieve
|
|
Business event
|
some happening outside the work scope, a demand for service provided by the work
|
|
Business use case
|
processing done in response to a business event
|
|
Product use case
|
a functional grouping of requirements that will be implemented by the product; the part of the BUC that you decide to build as a product
|