analysis Comparison Table

Object Oriented Software Engineering View all facts Glossary Help

Next process: build Up: process Previous process: verification

analysis comparison table

Subject include indicate define abbreviate as be is part of is a subtopic of perform after have risk require have purpose enable have benefits have procedure continue throughout assist stop has part use has definition help determine cover show teach in allow have objective have typical mistake perform before

cost-benefit analysis 9.3 - Techniques for Making Good Design Decisions add up estimates of the costs and compare this to the benefits The process of deciding whether to do something by evaluating the costs of doing it and the benefits of doing it, and then choosing to do it if the benefits sufficiently exceed the costs management courses

domain analysis opportunities for future development requirements and specification 4.1 - Domain Analysis software developers may make invalid assumptions and hence create poor requirements or design a software engineer to communicate with the stakeholders more effectively, so he will be able to establish requirements more quickly
Faster development
Better system
Anticipation of extensions
The process by which a software engineer learns enough background information so that he or she can understand the problem and make good decisions during requirements analysis and other stages of the software engineering process software engineer the subtleties of the domain, ensuring that the solutions adopted will more effectively solve the customer's problem a software engineer to focus on the most important issues, to make fewer mistakes, and to follow accepted procedures and standards requirements analysis

impact analysis 10.9 - Strategies for Testing Large Systems The process of exploring and documenting all possible effects of a change

object oriented analysis OOA 2.2 - Classes and Objects an understanding of whether objects are stored in random-access memory or on disk The process of deciding which classes will be important to the users, and working out the structure, relationships and behaviour of these classes

post-mortem analysis 10.11 - Quality Assurance in General The process of looking back at a completed project's design and its development process, in order to identify those aspects where improvements can be made in future projects

requirements analysis defining the problem to be solved and what software will be created to solve it requirements and specification 4.6 - Some Techniques for Gathering and Analyzing Requirements domain analysis
misunderstanding and lack of understanding of the domain or the real problem
Requirements can change rapidly, resulting in requirements 'churn'
attempting to do too much which occurs when inadequate boundaries have been placed on the problem or the solution, or when those boundaries are not respected
It may be hard to reconcile conflicting sets of requirements
It is hard to state requirements precisely
the life of a software system use case analysis The process of deciding on the requirements of a software system the responsibilities of a system over-constraint

root cause analysis 10.11 - Quality Assurance in General The process of determining the ultimate reason why a software engineer made the error introduced a defect to determine why a software engineer made the error that resulted in a defect occurring

task analysis 7.3 - Developing Use Case Models of Systems The process of determining the detailed steps needed to perform a task effectively and efficiently

use case analysis the scope of the system, i.e. what the system must do and does not have to do useful for requirements analysis 7.3 - Developing Use Case Models of Systems to model the system from the point of view of how users or other systems interact with this system when trying to achieve their objectives
determine the classes of users (or other systems) that will use the facilities of this system
to determine the tasks that each actor will need to do with the system
break each use case down into more detail
a software engineer to define the tasks that the user interface must help the user perform to eliminate proposed functionality if the functionality does not support any use case The process of dividing up the functionality of the system into use cases, and determining the relationships among those use cases developers model different user roles all aspects of software, such as an activity that is internal to a system

Next process: build Up: process Previous process: verification

Subject	include	indicate	define	abbreviate as	be	is part of	is a subtopic of	perform after	have risk	require	have purpose	enable	have benefits	have procedure	continue throughout	assist	stop	has part	use	has definition	help	determine	cover	show	teach in	allow	have objective	have typical mistake	perform before
cost-benefit analysis							9.3 - Techniques for Making Good Design Decisions							add up estimates of the costs and compare this to the benefits						The process of deciding whether to do something by evaluating the costs of doing it and the benefits of doing it, and then choosing to do it if the benefits sufficiently exceed the costs					management courses
domain analysis		opportunities for future development				requirements and specification	4.1 - Domain Analysis		software developers may make invalid assumptions and hence create poor requirements or design			a software engineer to communicate with the stakeholders more effectively, so he will be able to establish requirements more quickly	Faster development Better system Anticipation of extensions							The process by which a software engineer learns enough background information so that he or she can understand the problem and make good decisions during requirements analysis and other stages of the software engineering process				software engineer the subtleties of the domain, ensuring that the solutions adopted will more effectively solve the customer's problem		a software engineer to focus on the most important issues, to make fewer mistakes, and to follow accepted procedures and standards			requirements analysis
impact analysis							10.9 - Strategies for Testing Large Systems													The process of exploring and documenting all possible effects of a change
object oriented analysis				OOA			2.2 - Classes and Objects			an understanding of whether objects are stored in random-access memory or on disk										The process of deciding which classes will be important to the users, and working out the structure, relationships and behaviour of these classes
post-mortem analysis							10.11 - Quality Assurance in General													The process of looking back at a completed project's design and its development process, in order to identify those aspects where improvements can be made in future projects
requirements analysis	defining the problem to be solved and what software will be created to solve it					requirements and specification	4.6 - Some Techniques for Gathering and Analyzing Requirements	domain analysis	misunderstanding and lack of understanding of the domain or the real problem Requirements can change rapidly, resulting in requirements 'churn' attempting to do too much which occurs when inadequate boundaries have been placed on the problem or the solution, or when those boundaries are not respected It may be hard to reconcile conflicting sets of requirements It is hard to state requirements precisely						the life of a software system			use case analysis		The process of deciding on the requirements of a software system		the responsibilities of a system						over-constraint
root cause analysis							10.11 - Quality Assurance in General													The process of determining the ultimate reason why a software engineer made the error introduced a defect							to determine why a software engineer made the error that resulted in a defect occurring
task analysis							7.3 - Developing Use Case Models of Systems													The process of determining the detailed steps needed to perform a task effectively and efficiently
use case analysis			the scope of the system, i.e. what the system must do and does not have to do		useful for requirements analysis		7.3 - Developing Use Case Models of Systems				to model the system from the point of view of how users or other systems interact with this system when trying to achieve their objectives			determine the classes of users (or other systems) that will use the facilities of this system to determine the tasks that each actor will need to do with the system break each use case down into more detail		a software engineer to define the tasks that the user interface must help the user perform			to eliminate proposed functionality if the functionality does not support any use case	The process of dividing up the functionality of the system into use cases, and determining the relationships among those use cases	developers model different user roles		all aspects of software, such as an activity that is internal to a system