+0
Karma
| Class: | SWE 5110 - Requirements Engineering |
| Subject: | Software Engineering |
| University: | Florida Institute of Technology |
| Term: | Fall 2010 |
INCORRECT
CORRECT

|
Fit Criterion
|
Each functional requirement should have a fit criterion or a test case. In any event, the fit criterion is the benchmark to allow the tester to determine whether the implemented product has met the requirement # A measurement of the requirement such that it is possible to test if the solution matches the original requirement. |
|
Use Case
|
# A use case in software engineering and systems engineering is a description of a system-s behavior as it responds to a request that originates from outside of that system. (wiki) # The respond to the business event is called a business use case (book 73) A use case (or set of use cases) has these characteristics: Organizes functional requirements Models the goals of system/actor (user) interactions Records paths (called scenarios) from trigger events to goals Describes one main flow of events (also called a basic course of action), and possibly other ones, called exceptional flows of events (also called alternate courses of action) Is multi-level, so that one use case can use the functionality of another one. |
|
Domain Model
|
# A conceptual model of a domain of interest (often referred to as a problem domain) which describes the various entities, their attributes and relationships, plus the constraints that govern the integrity of the model elements comprising that problem domain. (wiki) # Modesl that capture the essence of a particular area of subject matters (p440) |
|
Context Diagram
|
A System Context Diagram (SCD) in software engineering and systems engineering is a diagram that represents the actors outside a system that could interact with that system. (wiki) |
Koofers.com
|
Rationale
|
Definition: A justification of the requirement |
|
Functional Requirement
|
Definition |
|
Non Functional Requirement
|
Definition |
|
Stakeholder
|
Definition |
Koofers.com
|
Business Event
|
Any system or peice of work reponds to things that happen outside it. (book 73) The respond to the business event is called a business use case |
|
Trawling for requirements Techniques (1)
|
1- Business use case workshop : the workshop allows us to work with a smaller number of specialized stakeholders at a time (p113) 2- Persona: is an inveted presonality, an imaginary user for whom you are gathering requirements for your product. (119) are uesfull when real users are not available or are too numerous to interview all of them. (119) || uses a composite virtual character to represent the user/customer |
|
Trawling for requirements Techniques (2)
|
3- Apprenticing : Spends timeworking with an expert useful for in-house work. the assumption is that the users are doing the work. This work can be clerical, commercial , or almost anything short of brain surgery. but to keep in mind not to attempt to reimplement the work exactly as is. (p101) e.g. Go to workplace and site alongside side with the user to get every detail explained as it is occuring. |
|
Trawling for requirements Techniques (3)
|
4- Scenarios: describes the work being done by the business use case as a series usually between three and ten steps. They are not very detailed, just to capture a broad picture of the work.(p115) To show the functionality of a use case |
Koofers.com
|
What is a requirements baseline?(1-2)
|
Once all Business Requirements have been reviewed and approved, the baseline requirements is established. This results in the creation of the first official Business Requirements Document. http://www.requirementsauthority.com/baseline-requirements.html |
|
What is the purpose of placing requirements under
configuration control?(2-2)
|
to ensure that any requirements chages are fully coordinated and documented. |
|
Describe a typical requirements configuration control procedure
|
Definition |
Koofers.com
Front |
Back |
|
|---|---|---|
| Fit Criterion | Each functional requirement should have a fit criterion or a test case. In any event, the fit criterion is the benchmark to allow the tester to determine whether the implemented product has met the requirement # A measurement of the requirement such that it is possible to test if the solution matches the original requirement. | |
| Use Case | # A use case in software engineering and systems engineering is a description of a system-s behavior as it responds to a request that originates from outside of that system. (wiki) # The respond to the business event is called a business use case (book 73) A use case (or set of use cases) has these characteristics: Organizes functional requirements Models the goals of system/actor (user) interactions Records paths (called scenarios) from trigger events to goals Describes one main flow of events (also called a basic course of action), and possibly other ones, called exceptional flows of events (also called alternate courses of action) Is multi-level, so that one use case can use the functionality of another one. | |
| Domain Model | # A conceptual model of a domain of interest (often referred to as a problem domain) which describes the various entities, their attributes and relationships, plus the constraints that govern the integrity of the model elements comprising that problem domain. (wiki) # Modesl that capture the essence of a particular area of subject matters (p440) | |
| Context Diagram | A System Context Diagram (SCD) in software engineering and systems engineering is a diagram that represents the actors outside a system that could interact with that system. (wiki) | |
| Rationale | Definition: A justification of the requirement | |
| Functional Requirement | Definition | |
| Non Functional Requirement | Definition | |
| Stakeholder | Definition | |
| Business Event | Any system or peice of work reponds to things that happen outside it. (book 73) The respond to the business event is called a business use case | |
| Trawling for requirements Techniques (1) | 1- Business use case workshop : the workshop allows us to work with a smaller number of specialized stakeholders at a time (p113) 2- Persona: is an inveted presonality, an imaginary user for whom you are gathering requirements for your product. (119) are uesfull when real users are not available or are too numerous to interview all of them. (119) || uses a composite virtual character to represent the user/customer | |
| Trawling for requirements Techniques (2) | 3- Apprenticing : Spends timeworking with an expert useful for in-house work. the assumption is that the users are doing the work. This work can be clerical, commercial , or almost anything short of brain surgery. but to keep in mind not to attempt to reimplement the work exactly as is. (p101) e.g. Go to workplace and site alongside side with the user to get every detail explained as it is occuring. | |
| Trawling for requirements Techniques (3) | 4- Scenarios: describes the work being done by the business use case as a series usually between three and ten steps. They are not very detailed, just to capture a broad picture of the work.(p115) To show the functionality of a use case | |
| What is a requirements baseline?(1-2) | Once all Business Requirements have been reviewed and approved, the baseline requirements is established. This results in the creation of the first official Business Requirements Document. http://www.requirementsauthority.com/baseline-requirements.html | |
| What is the purpose of placing requirements under configuration control?(2-2) | to ensure that any requirements chages are fully coordinated and documented. | |
| Describe a typical requirements configuration control procedure | Definition |
© Copyright 2012 , Koofers, Inc. All rights reserved.
The information provided on this site is protected by U.S. and International copyright law, and other applicable intellectual property laws, including laws covering data access and data compilations. This information is provided exclusively for the personal and academic use of students, instructors and other university personnel. Use of this information for any commercial purpose, or by any commercial entity, is expressly prohibited. This information may not, under any circumstances, be copied, modified, reused, or incorporated into any derivative works or compilations, without the prior written approval of Koofers, Inc.